A call system

Abstract

The embodiment of the application provides a kind of calling system, it is related to computer software and information technology field, the system includes: call control cluster, media server cluster, load balancer and registration center;Registration center is used to register the information of each cluster in call control cluster and each cluster in media server cluster;Load balancer distributes outgoing service request to the first target call control instance in call control cluster;First target call control instance is used to determine the first target media server instance in media server cluster, and sends target call instruction to the first target media server instance based on outgoing service request;First target media server instance is used to establish the two-way media stream transmission channel between the first target user and the first target agent in outgoing service request.The embodiment of the application is used to provide a kind of technical scheme for solving the problems that existing call system lacks rich interface support, is not easy to do business integration and operation and maintenance.

Description

Technical Field

[0001] This application relates to the field of computer software and information technology, and in particular to a call system. Background Technology

[0002] A call system (also known as a call center system or customer service system) is a comprehensive communication and business management system that enables efficient interaction between businesses and their customers (or users) through multiple channels such as telephone, online chat, etc. It is a core tool for businesses to conduct customer service, sales and marketing, and business consultation. It typically includes inbound and outbound call services. Inbound call services are when users connect to the platform, and can be divided into two types based on the service method: one-to-one and one-to-many.

[0003] In a one-to-one scenario, each agent has a fixed incoming number, and that agent will serve any user who dials that number. In a one-to-many scenario, each incoming number is served by multiple agents. When a user dials the incoming number, an agent is selected from among these multiple agents according to an allocation strategy. Outbound call services involve agents calling users, including automated outbound calls and manual outbound calls.

[0004] However, the existing call system lacks rich interface support, making it difficult to perform business integration and maintenance, and unable to meet the needs of rapid business iteration. Summary of the Invention

[0005] This application provides a call system as a technical solution to address the problems of existing call systems lacking rich interface support, being difficult to integrate and maintain, and failing to meet the needs of rapid business iteration.

[0006] In a first aspect, this application provides a calling system, the system comprising:

[0007] Call control cluster, media server cluster, load balancer, and registry center;

[0008] The registration center is used to register information about each cluster in the call control cluster and each cluster in the media server cluster;

[0009] The load balancer is used to respond to outbound service requests sent by the front-end interactive interface and allocate the outbound service requests to a first target call control instance in the call control cluster; wherein, the first target call control instance is a call control instance in the call control cluster that is in an online state.

[0010] The first target call control instance is configured to determine a first target media server instance in the media server cluster based on state information of each media server instance of the media server cluster in the registration center, and send a target call instruction to the first target media server instance based on the outbound service request;

[0011] The first target media server instance is configured to establish a bidirectional media stream transmission channel between the first target user and the first target agent in the outbound service request according to a media parameter in the target call instruction.

[0012] Based on the above, the embodiment of the present application provides a call system, which comprises a call control cluster, a media server cluster, a load balancer and a registration center; the registration center is configured to register information of each cluster in the call control cluster and information of each cluster in the media server cluster.

[0013] Based on this, the call control cluster and the media server cluster in the embodiment of the present application are deployed in multiple instances, and the registration center registers information of each cluster for management. Therefore, the registration center can dynamically increase or decrease the number of instances according to the business volume, so as to solve the problems of difficult expansion and obvious bottleneck of the traditional single-node system, and support the expansion of the business scale. In the embodiment of the present application, the load balancer distributes the outbound service request to the first target call control instance which is online and has sufficient resources, and in combination with real-time monitoring of the cluster state by the registration center, service interruption caused by single-instance failure can be avoided, the overall availability of the system is improved, and the risk of single-point failure is reduced.

[0014] In addition, based on the unified registration of instance information of each cluster by the registration center, an operator does not need to manually maintain the calling relationship between instances (when a new instance is added or an offline instance is added, the registration center automatically synchronizes the state), thereby reducing the operation and maintenance complexity. At the same time, the cluster deployment supports partial instance upgrading and partial instance normal service, thereby avoiding service interruption during the upgrading process.

[0015] In the embodiment of the present application, the call control, media service, load balancing and other functional modules are decoupled through standardized interfaces. When the business requirement changes, the corresponding modules can be upgraded individually without the need to reconstruct the system as a whole, thereby meeting the requirement of rapid iteration of the business.

[0016] Furthermore, in the embodiment, the first target call control instance is configured to determine a first target media server instance in the media server cluster based on state information of each media server instance of the media server cluster in the registration center, and send a target call instruction to the first target media server instance based on the outbound service request; and the first target media server instance is configured to establish a bidirectional media stream transmission channel between the first target user and the first target agent in the outbound service request according to a media parameter in the target call instruction.

[0017] Based on the above description, the first target call control instance selects the optimal first target media server instance through the state information of each media server instance in the media server cluster, ensures the efficiency of media stream processing (such as bidirectional audio and video transmission), reduces the call delay or failure probability, and improves the call experience of users and agents. The call control cluster focuses on call logic scheduling (such as instance selection and instruction generation), and the media server cluster focuses on media stream channel establishment. The two have separate responsibilities and interact through standardized instructions, can handle multiple outbound call requests in parallel, and improve the concurrent processing capability of the system.

[0018] Finally, in the embodiment of the present application, service discovery and invocation are realized through the linkage of the registration center to the load balancer, and a standardized internal service interaction mechanism is constructed. This mechanism can be further extended as an external interface, facilitating integration with enterprise CRM (Customer Relationship Management), ticket system and other business systems, to solve the problems of insufficient interface support and integration difficulty of existing systems. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 A structural schematic diagram of a call system provided by the embodiment of the present application;

[0020] Figure 2 An interaction flowchart of an outbound call scenario of a call system provided by the embodiment of the present application;

[0021] Figure 3 An interaction flowchart of an inbound call scenario of a call system provided by the embodiment of the present application;

[0022] Figure 4 A specific structural schematic diagram of a call system provided by the embodiment of the present application. DETAILED DESCRIPTION

[0023] A call system (also called a call center system or a customer service system) is a comprehensive communication and business management system that realizes efficient interaction between enterprises and customers (or users) through multiple channels such as telephone, online chat, etc. It is the core tool for enterprises to carry out customer service, sales and marketing, business consultation and other scenarios. It usually includes inbound and outbound services. Inbound service is that users call into the platform, which can be divided into one-to-one and one-to-many according to the service mode.

[0024] In a one-to-one scenario, each agent has a fixed inbound number, and no matter which user dials the inbound number, the agent will serve the user. In a one-to-many scenario, each inbound number is served by multiple agents, and when a user dials an inbound number, an agent is selected from the multiple agents to serve the user according to an allocation strategy. Outbound service is that an agent calls a user, including automatic outbound and manual outbound.

[0025] However, the existing call system lacks rich interface support, is not easy to integrate and operate, and cannot meet the rapid iteration of business.

[0026] Therefore, the technical concept of the embodiments of the present application is to provide a cluster and service management architecture to solve the problems of insufficient interface, difficult integration and operation, and slow iteration of the existing call system. The registration center is used to uniformly manage the cluster instance information of call control, media server, etc., to realize service dynamic registration and state monitoring; the load balancer intelligently distributes outbound requests based on the instance state to ensure efficient use of resources; the call control and media server work together, the former is responsible for scheduling and decision-making, and the latter handles media streams, and the scalability is improved through component decoupling. The overall design supports dynamic expansion and fault self-healing, simplifies operation and business integration, and meets the rapid iteration requirements.

[0027] In the following, the technical solutions shown in the present application will be described in detail through specific embodiments. It should be noted that the following embodiments can exist independently or be combined with each other, and the same or similar contents will not be repeated in different embodiments.

[0028] With reference to Figure 1 , in a first aspect, the embodiments of the present application provide a call control cluster, a media server cluster, a load balancer and a registration center;

[0029] The registration center is used to register the information of each cluster in the call control cluster and each cluster in the media server cluster;

[0030] The load balancer is used to distribute the outbound service request to a first target call control instance in the call control cluster in response to the outbound service request sent by the front-end interactive interface; wherein the first target call control instance is a call control instance in an online state in the call control cluster;

[0031] The first target call control instance is used to determine a first target media server instance in the media server cluster based on the state information of each media server instance in the media server cluster in the registration center, and send a target call instruction to the first target media server instance based on the outbound service request;

[0032] The first target media server instance is used to establish a bidirectional media stream transmission channel between the first target user and the first target agent in the outgoing service request, based on the media parameters in the target call instruction.

[0033] In the embodiments of this application, reference is made to Figure 1 The registration center is responsible for uniformly registering information (such as IP, port, service type) of each instance in the call control cluster and information (such as load rate, encoding and decoding capabilities, online status) of each instance in the media server cluster, and updating the instance status in real time (such as automatic marking when there is a fault or offline), and providing service catalog support for other components.

[0034] The load balancer receives outbound service requests sent from the front-end interactive interface. These requests include the first target user number, the first target agent ID, and the service type. Based on the call control cluster instance status synchronized with the registry center, the load balancer selects the first target call control instance that is online and has sufficient resources, and distributes the request to that instance to avoid forwarding the request to a faulty instance.

[0035] The first target call control instance obtains real-time status information of each instance in the media server cluster from the registry center, such as current call volume, resource utilization, and supported media formats, and filters out the first target media server instance that is suitable for the current outbound call service; then it generates a target call instruction based on the outbound service request and sends it to the first target media server instance.

[0036] For example, the target call instruction includes the user's and agent's terminal information, media parameters such as codec format / transmission port, and service tag.

[0037] The first target media server instance parses the media parameters in the target call command and establishes media links with the terminal of the first target user (such as a mobile phone or SIP device) and the front-end interactive interface of the first target agent (adapted after protocol conversion). By negotiating and unifying the media formats of both parties, it finally bridges the bidirectional audio and video stream transmission channel between the user and the agent, and completes the outbound call establishment.

[0038] Based on this, the call control cluster and media server cluster in this embodiment are deployed using multiple instances. The registration center registers and manages information for each cluster. Therefore, the registration center can dynamically increase or decrease the number of instances according to the business volume, thus solving the problems of difficult expansion and obvious bottlenecks in traditional single-node systems, and supporting the expansion of business scale. The load balancer only allocates outgoing call service requests to the first target call control instance that is online and has sufficient resources. Combined with the real-time monitoring of the cluster status by the registration center, service interruptions caused by single instance failures can be avoided, improving the overall availability of the system and reducing the risk of single point of failure.

[0039] Furthermore, the registration center uniformly registers information for all cluster instances, eliminating the need for operations and maintenance personnel to manually maintain the call relationships between instances (the registration center automatically synchronizes the status when adding / deleting instances), thus reducing operational complexity. Simultaneously, clustered deployment supports the upgrading of some instances while maintaining normal service for others, avoiding service interruptions during upgrades. Functional modules such as call control, media services, and load balancing are decoupled through standardized interfaces. When business requirements change, the corresponding modules can be upgraded individually without requiring a complete system rebuild, meeting the needs of rapid business iteration.

[0040] Furthermore, the primary target call control instance selects the optimal primary target media server instance based on the status information of each media server instance in the media server cluster. This ensures the efficiency of media stream processing (such as bidirectional audio and video transmission), reduces call latency or failure probability, and improves the call experience for both users and agents. The call control cluster focuses on call logic scheduling (such as instance selection and instruction generation), while the media server cluster focuses on establishing media stream channels. Their responsibilities are separated, and they interact through standardized instructions, enabling parallel processing of multiple outbound call requests and enhancing the system's concurrent processing capabilities.

[0041] Finally, in this embodiment, service discovery and invocation are achieved through the linkage between the registry center and the load balancer, constructing a standardized internal service interaction mechanism. This mechanism can be further extended into an external interface, facilitating integration with business systems such as enterprise CRM and work order systems, thereby solving the problems of insufficient interface support and integration difficulties in existing systems.

[0042] In one optional implementation, the outbound service request is generated by the first target agent after performing a specific operation on the front-end interactive interface; wherein, the outbound service request includes information of the first target user, the identifier of the first target agent, and the service type.

[0043] In this embodiment, after the first target agent performs a series of specific operations through a front-end interactive interface (such as a customer service workbench or a web agent client), the system automatically generates an outbound service request. The specific operations include: the agent querying the first target user's information on the front-end interface (e.g., selecting a user from a customer list associated with the CRM system), clicking the outbound call button, and selecting the service type tag for this call (e.g., manually checking after-sales follow-up or product promotion). After the operations are completed, the front-end interface submits the request to the load balancer through a preset interface.

[0044] The information of the primary target user includes the user's unique identifier (such as mobile phone number or landline number), basic attributes (such as location and user level tags), and a summary of historical interaction records (such as inquiries about order issues made 3 days ago), providing a user profile basis for subsequent call processing.

[0045] The identifier for the first target agent includes the agent's employee number, team (e.g., After-sales team 1), and skill tags (e.g., proficient in handling order disputes), which are used by the system to trace the caller and match the corresponding permissions. The business type of the first target agent is used to clarify the business scenario of this call (e.g., after-sales problem follow-up, new feature recommendation, satisfaction survey), which can serve as the basis for call control instance to schedule media resources and execute business logic.

[0046] Based on the above description, outbound service requests are generated proactively by agents and include user information, agent identification, and service type. This avoids blind calls without a clear subject or scenario, ensuring that each outbound call corresponds to a specific user need or business objective (such as after-sales follow-up only for users with historical issues), thus improving outbound call efficiency and quality.

[0047] Information such as user tags, agent skills, and service types carried in outgoing call requests can be directly used by the call control instance for media server selection and call logic adaptation (such as enabling recording quality inspection in sales scenarios), reducing information query costs in subsequent processes and accelerating call setup efficiency.

[0048] Agents generate requests through visual operations on the front-end interactive interface (such as selecting users or choosing business types), eliminating the need to manually input complex parameters and lowering the operational threshold. At the same time, the front-end interface is linked with business systems such as CRM (such as initiating outbound calls directly from the customer list), achieving seamless connection between business data and outbound operations and enhancing the system's business empowerment capabilities.

[0049] Outbound requests have clearly defined request information (user information, agent ID, service type) to form a standardized interface specification, which facilitates interaction between modules such as the front-end interactive interface, call control cluster, and media server in a unified format. When a new service type is added, only the service type field and corresponding logic need to be extended, without the need to refactor the request generation and parsing mechanism, supporting rapid business iteration.

[0050] Optional, refer to Figure 1 The system also includes a SIP registration server cluster and a protocol conversion gateway cluster;

[0051] The registration center is also used to register information about each cluster in the SIP registration server cluster and each cluster in the protocol conversion gateway cluster.

[0052] The first target media server instance is further configured to generate a first call signaling for the first target agent according to the target call instruction, and send the first call signaling to the first target SIP registration server instance in the SIP registration server cluster;

[0053] The first target SIP registration server instance is used to determine the first target protocol conversion gateway instance in the protocol conversion gateway cluster based on the registration status information and registration location of the first target agent, and to route the first call signaling to the first target protocol conversion gateway instance;

[0054] The first target protocol conversion gateway instance is used to convert the first call signaling into a protocol recognizable by the first front-end interactive interface, and forward the first call signaling after protocol conversion to the first front-end interactive interface;

[0055] The first front-end interactive interface is used to automatically respond to the first call signaling after the protocol conversion, start collecting the audio and video information of the first target agent, generate target media parameters, and return the target media parameters to the first target media server instance through the first target protocol conversion gateway and the first target SIP registration server instance.

[0056] The first target media server instance is further configured to establish a first media stream transmission sub-channel with the first front-end interactive interface based on the target media parameters. The first media stream transmission sub-channel is used to transmit the audio and video data of the first target agent.

[0057] In this embodiment, the registration center is also used to synchronously register information of the SIP registration server cluster (IP, service port, and load status of each instance) and the protocol conversion gateway cluster (the protocol types supported by each instance, such as SIP to WebSocket and resource utilization), providing unified support for end-to-end service discovery and status awareness.

[0058] After parsing the target call instruction, the first target media server instance generates a first call signaling (such as SIP INVITE, including the agent identifier and media negotiation initial parameters) for the first target agent, and sends the signaling to the first target SIP registration server instance in the SIP registration server cluster that is in a healthy state, based on the information from the registration center.

[0059] Subsequently, the first target SIP registration server instance queries the first target agent registration status information (such as whether it is online and the last registration time) and registration location (i.e. the protocol conversion gateway address and port associated with the agent when logging in) stored locally, matches the corresponding first target protocol conversion gateway instance from the protocol conversion gateway cluster, and routes the first call signaling to that instance.

[0060] After receiving the first call signaling in SIP format, the first target protocol conversion gateway instance converts it into a protocol recognizable by the first front-end interactive interface (such as the WebSocket protocol, to adapt to the real-time communication needs of the browser), and forwards the converted signaling to the first front-end interactive interface.

[0061] The first front-end interactive interface responds to the converted signaling and automatically performs the response operation (no manual triggering required by the agent, simplifying the operation). At the same time, it starts the audio and video acquisition module (calling the browser's camera and microphone), generates target media parameters on the agent side (such as audio encoding format G.711, video encoding H.264, local IP and transmission port), and returns the parameters to the first target media server instance through the first target protocol conversion gateway (converting to SIP protocol) and the first target SIP registration server instance.

[0062] Based on the returned target media parameters, the first target media server instance establishes a first media stream transmission sub-channel with the first front-end interactive interface through the first target protocol conversion gateway. This sub-channel is specifically used for real-time transmission of audio and video data of the first target agent (such as voice collected by the microphone and video captured by the camera), providing a foundation for subsequent bridging with the user-side media stream.

[0063] Based on the above description, the protocol conversion gateway cluster realizes bidirectional conversion between SIP and WebSocket (Web front-end protocol), enabling browser-based front-end interactive interfaces to communicate seamlessly with back-end SIP protocol media servers and registration servers. This breaks through the limitation of incompatibility between traditional communication protocols and Web terminals, and supports agents to access the system through lightweight terminals such as computers and mobile browsers, thus expanding the range of terminal adaptation.

[0064] The SIP registration server cluster uses the location information (associated protocol conversion gateway) recorded during agent registration to route signaling, avoiding blind forwarding of signaling within the cluster. At the same time, the registration center synchronizes the status of each instance in real time, ensuring that signaling is only routed to healthy instances, reducing signaling loss or delay, and improving the processing efficiency of call signaling on the agent side.

[0065] The SIP registration server and protocol conversion gateway are both deployed in a cluster. Combined with the dynamic registration and status monitoring of the registration center, it can be elastically expanded as the number of agents increases (new instances are automatically connected to the cluster). When an instance fails, the registration center will quickly mark and redirect traffic to healthy instances to ensure the continuity of the call link on the agent side and support large-scale concurrent scenarios.

[0066] In an optional implementation, the first target media server instance is further configured to:

[0067] After generating the first call signaling, a seat call start event is sent to the first target call control instance;

[0068] The first target protocol conversion gateway instance is used to forward the converted call instruction to the first front-end interactive interface, and after the first front-end interactive interface enters the agent ringing state, it sends an agent ringing event to the first target call control instance.

[0069] Upon receiving the target media parameters, a seat answering event is sent to the first target call control instance;

[0070] When a media stream transmission channel is established with the first front-end interactive interface, a user call start event is sent to the first target call control instance; wherein, the user call start event is used to indicate that the audio and video media streams between the first target agent and the first target user have started bidirectional transmission.

[0071] The first target call control instance is also used for:

[0072] In response to the agent call start event, the call start timestamp of the first target agent is recorded synchronously;

[0073] In response to the seat ringing event, the ringing timestamp of the first target seat is recorded synchronously;

[0074] In response to the seat answering event, the answering timestamp of the first target seat is recorded synchronously;

[0075] In response to the user call start event, the call start timestamp for the first target user is recorded synchronously.

[0076] In this embodiment, the first target media server instance and the first target call control instance achieve real-time synchronization and data recording of the entire outgoing call process status through an event triggering and timestamp recording mechanism. The specific interaction is as follows:

[0077] After the first target media server instance generates the first call signaling (used to call the first target agent), it immediately sends an agent call start event (carrying the agent identifier and signaling generation time) to the first target call control instance. The first target call control instance responds to the event, synchronously records the call start timestamp of the first target agent, and marks that the agent-side call signaling has been initiated.

[0078] When the first target protocol conversion gateway instance forwards the converted call instruction to the first front-end interactive interface, and the front-end interface enters the agent ringing state (such as interface pop-up and ringtone prompt), the first target media server instance detects the ringing state and sends an agent ringing event (carrying agent identifier and ringing start time) to the first target call control instance. The first target call control instance responds to the event, records the ringing timestamp of the first target agent, and marks that the agent has started ringing reminders.

[0079] After receiving the target media parameters (indicating that the agent has completed audio and video acquisition preparation) returned by the first front-end interactive interface, the first target media server instance sends an agent answering event (carrying the agent identifier and parameter reception time) to the first target call control instance. The first target call control instance responds to the event, records the first target agent's answering timestamp, and marks that the agent has completed answering preparation.

[0080] When the first target media server instance successfully establishes the first media stream transmission sub-channel with the first front-end interactive interface (audio and video stream transmission begins on the agent side), and the media link with the first target user terminal is also established (audio and video stream transmission begins on the user side), the media server sends a user call start event (carrying user identifier, agent identifier, and bidirectional stream start time) to the first target call control instance, indicating that bidirectional transmission of audio and video streams between the two parties has been achieved. The first target call control instance responds to this event, records the call start timestamp for the first target user, and marks the formal entry of the call into the interactive phase.

[0081] Based on the above description, in this embodiment of the application, each key node (signaling initiation, ringing, answering, and streaming) from the initiation of a call by an agent to the start of a two-way conversation is recorded through event triggering and timestamps, forming a complete process log. Maintenance personnel can use the timestamp sequence to locate process bottlenecks (e.g., excessively long ringing to answering time may indicate slow agent response or media parameter negotiation delays), quickly troubleshooting call failures, delays, and other issues, thus improving maintenance efficiency.

[0082] Timestamp data can provide quantitative evidence for service quality assessment. For example, by statistically analyzing the average ringing time of agents, agent response efficiency can be optimized; by analyzing the total call setup time for different service types, performance bottlenecks of media servers or protocol conversion gateways can be identified, and resource allocation can be optimized accordingly.

[0083] Furthermore, timestamp data can be linked to business rules (such as automatically transferring a call to another agent if it remains unanswered after 30 seconds of ringing). The call control instance calculates the waiting time in real time based on the recorded ringing timestamps, triggering automated processes and avoiding delays caused by manual intervention. At the same time, complete time records can serve as an objective basis for agent performance evaluation (such as answering speed and call preparation efficiency), promoting service standardization.

[0084] The first target media server instance and the first target call control instance use an event and timestamp binding mechanism to ensure that both parties have consistent perceptions of the status of the same process node (such as the media server confirming the ringing and the call control recording the ringing time corresponding), avoiding business logic confusion caused by asynchronous status (such as the agent has answered the call but the system still judges it as ringing), and improving the reliability of cross-module collaboration.

[0085] Optional, refer to Figure 1 The system also includes a call gateway cluster;

[0086] The first target call control instance is further configured to determine the first target call gateway instance in the call gateway cluster based on the attribute information of the first target user in the outgoing call service request, and in combination with the load status and line adaptability of each call gateway instance in the call gateway cluster.

[0087] The first target media server instance is further configured to generate a second call signaling for the first target user according to the target call instruction, and send the second call signaling to the first target call gateway instance;

[0088] The first target call gateway instance is used to convert the second call signaling to a protocol format supported by the external line operator, and to route the protocol-converted second call signaling to the external line operator to request the external line operator to initiate a call to the first target user.

[0089] In this embodiment, a complete link is also established from the internal call request to the external line provider, realizing the initiation of a call to the first target user. The specific process is as follows:

[0090] The first target call control instance parses the first target user attribute information (such as the user's number location, the number's operator, and the number type) from the outbound service request. Simultaneously, it obtains the real-time status of each instance in the call gateway cluster through the registry center, including load status (such as the current call volume and CPU / memory usage) and line compatibility (such as whether it supports a specific line, whether it covers a specific region's communication links, and supported external protocol types). Based on this information, the instance with the lowest load and the highest match to the user attributes is selected as the first target call gateway instance.

[0091] Subsequently, the first target media server instance generates a second call signaling (such as SIP INVITE, carrying the user number and system-side media initial parameters) for the user based on the target call instruction (including the first target user number and media negotiation parameters), and sends the signaling to the identified first target call gateway instance.

[0092] After receiving the second call signaling (usually SIP protocol internally), the first target call gateway instance converts the second call signaling into a protocol format supported by the line operator according to the pre-configured external line operator protocol specifications, and supplements the additional information required by the line operator. Subsequently, the converted second call signaling is routed to the corresponding external line operator, requesting it to initiate a call to the terminal (such as mobile phone or landline) of the first target user (i.e., trigger the user terminal to ring).

[0093] Based on the above description, the call gateway cluster undertakes the protocol conversion function, converting the unified SIP signaling within the system into the adapted protocol of external line providers. This solves the limitation of incompatibility between the system and different line providers' protocols, enabling the system to flexibly connect to multiple line providers and avoid dependence on a single line.

[0094] The call gateway adopts a clustered deployment, combined with the dynamic status management of the registration center, and can be elastically expanded according to the traffic volume (such as peak outbound calls) (new gateway instances are automatically registered and take over traffic); when a gateway instance fails or the line is interrupted, the system can quickly switch to other healthy instances to ensure communication continuity with external line providers and support large-scale concurrent outbound call scenarios.

[0095] The call gateway cluster centrally handles protocol adaptation and line configuration (such as number authentication and routing rules) with external line providers. Internal systems (media servers and call control) do not need to care about the details of external protocols and only interact with the gateway through standardized interfaces, which reduces the development cost of system integration with new line providers. At the same time, maintenance personnel can uniformly monitor the line status and load of each gateway through the cluster management interface, simplifying the process of troubleshooting line faults and adjusting resources.

[0096] Optionally, the first target call gateway instance is further configured to receive the ringing response returned by the external line operator and return the ringing response to the first target media server instance;

[0097] The first target media server instance is also configured to send a user ringing event to the first target call control instance after receiving the ringing response;

[0098] In response to the user ringing event, the first target call control instance synchronously records the ringing timestamp of the first target user and publishes the ringing event of the first target user to the load balancer.

[0099] The load balancer is used to forward the ringing event of the first target user to the first front-end interactive interface;

[0100] The first front-end interactive interface is used to send the ringing event of the first target user to the first target agent.

[0101] In this embodiment, after an external line operator initiates a call to the first target user (e.g., the user's mobile phone starts ringing), it returns a ringing response (with a protocol format adapted to the line operator) to the first target call gateway instance. This response includes information such as the user identifier and the ringing start time. The first target call gateway instance converts the ringing response into a system-compatible format (e.g., uniformly converting it to a SIP protocol message) and forwards it to the first target media server instance, informing the first target media server instance that the user terminal has started ringing.

[0102] After receiving the ringing response, the first target media server instance parses the user's ringing status, generates a user ringing event (carrying the first target user identifier, ringing response reception time, and line provider information), and sends the event to the first target call control instance to synchronize the real-time status on the user side.

[0103] The first target call control instance responds to the user's ringing event and immediately records the ringing timestamp of the first target user to mark the node where the user started ringing. At the same time, to ensure that the agent is aware of the user's status in real time, the call control instance publishes the first target user's ringing event (including user identifier and ringing timestamp) to the load balancer, requesting that it be forwarded to the front-end interaction interface of the first target agent.

[0104] The load balancer, based on the first target agent identifier (associated with the first front-end interaction interface) carried in the event, queries the front-end interface instance status recorded in the registry center (such as online status and bound agent ID), and forwards the user ringing event to the first front-end interaction interface. After receiving the event, the first front-end interaction interface sends a notification to the first target agent in a visual manner (such as the interface displaying that the user is ringing and asking the agent to wait to answer), informing the first target agent that the user has started ringing and that they need to prepare for the subsequent call.

[0105] Based on the above description, this application embodiment ensures that the agent can perceive the status as soon as the user's terminal rings, from the external line provider's return of the ringing response to the agent receiving the notification. This avoids the agent being forced to wait passively due to information lag, and allows the agent to prepare user information and organize communication scripts in advance, thereby improving service professionalism.

[0106] The user ringing timestamp recorded in the first target call control instance, together with the aforementioned timestamps for the first target agent's call start, ringing, and answer, constitutes a complete call flow timeline. This timeline allows for the quantification of the time consumed at each stage, providing data for optimizing line quality and media server response speed.

[0107] Ringing events are transmitted through a standardized link involving the call gateway, media server, call control, load balancer, and front-end interface. This ensures that all system components have a consistent understanding of the user's ringing status, avoids business logic errors caused by asynchronous status, and improves the stability of cross-module collaboration within the system.

[0108] In an optional implementation, the first target call gateway instance is further configured to receive the answer response returned by the external line operator and return the answer response to the first target media server instance;

[0109] The first target media server instance is also configured to send a user answer event to the first target call control instance after receiving the answer response;

[0110] In response to the user answering event, the first target call control instance synchronously records the first target user's answer timestamp and publishes the first target user's answering event to the load balancer.

[0111] The load balancer is used to forward the answering event of the first target user to the first front-end interactive interface;

[0112] The first front-end interactive interface is used to publish the call answering event of the first target user to the first target agent.

[0113] This implementation method realizes the information transmission from the external line operator confirming the user's answer to the agent's real-time awareness. The specific steps are as follows:

[0114] When the first target user answers the call, the external line provider returns an answer response to the first target call gateway instance. This response includes information such as the user identifier, answer time, and terminal media capabilities. The first target call gateway instance converts the answer response into a system-compatible format and forwards it to the first target media server instance, informing the user that the call has been answered.

[0115] Afterwards, the first target media server instance receives the answer response, parses the user's answer status and terminal media parameters, generates a user answer event (carrying the first target user identifier, answer response reception time, and user terminal media capability summary), and sends the event to the first target call control instance to synchronize the key status changes on the user side.

[0116] The first target call control instance responds to the user's answer event and immediately records the first target user's response timestamp to mark the point at which the user has completed answering the call. Simultaneously, to ensure that the agent is promptly aware that the user has connected, the call control instance publishes the first target user's answer event to the load balancer, requesting that it be forwarded to the first target agent's first front-end interaction interface.

[0117] Finally, based on the first target agent identifier carried in the event, the load balancer queries the registry center to check the status of the first front-end interaction interface (such as online, binding relationship), and forwards the user answer event to that first front-end interaction interface. After receiving the event, the first front-end interaction interface sends a notification to the first target agent in a visual manner (such as the interface showing that the user has answered and can start the call, and the call interface switching from "waiting" to "in call"), informing the agent that the user has joined and can officially start the interaction.

[0118] Based on the above description, this application embodiment confirms the end-to-end transmission from the external line provider's confirmation of the user's answer to the agent receiving the notification, ensuring that the agent can sense the user's answer the moment the call is answered, avoiding communication gaps caused by information delays, ensuring the naturalness of call connection, and improving user experience.

[0119] In an optional implementation, the first target media server instance is further configured to terminate the media stream transmission with the first target agent after receiving the first target agent hang-up instruction forwarded by the first front-end interactive interface, generate a first target agent hang-up event, and publish the first target agent hang-up event to the first target call control instance.

[0120] The first target call control instance is also used to synchronously record the hang-up timestamp of the first target agent in response to the hang-up event of the first target agent.

[0121] In this embodiment, a complete link from agent operation to system status synchronization and data recording is implemented. The specific steps are as follows:

[0122] After the first target agent completes the call with the first target user, the first front-end interactive interface performs a hang-up operation. The front-end interface generates a hang-up command for the first target agent (including agent identifier and operation timestamp) and forwards the command to the first target media server instance through the protocol conversion gateway (the command format is adapted to the media server protocol, such as SIP BYE signaling).

[0123] After receiving the agent hang-up command, the first target media server instance then performs the following operations:

[0124] Terminate the media streaming subchannel with the first target seat;

[0125] Generate the first target agent hang-up event, which carries key information such as agent identifier, media stream termination time, and call duration (calculated based on the agent's answer timestamp and the current time);

[0126] The hang-up event is published to the first target call control instance in a standardized format (such as the system's internal event protocol) to synchronize the call termination status on the agent side.

[0127] Finally, the first target call control instance responds to the first target agent's hang-up event and records the hang-up timestamp of the first target agent. This timestamp, together with the previously recorded timestamps of agent call start, ringing, and answering, forms complete agent-side call lifecycle data.

[0128] Based on the above description, the media server immediately terminates the media stream transmission and releases resources such as ports and bandwidth after receiving the hang-up command, avoiding invalid resource occupation caused by the agent hanging up but the stream still being transmitted; at the same time, the hang-up event is synchronized to the call control instance to ensure that all system components (such as call control and front-end interface) have a consistent understanding of the call termination status, avoiding subsequent misoperations.

[0129] By combining the agent's hang-up timestamp with the timestamps of previous stages, the actual call duration can be accurately calculated, providing core data for customer service performance evaluation and business cost accounting. At the same time, the complete time series can be used to trace the call process, meeting the needs of service quality monitoring.

[0130] Optional, refer to Figure 1 The system also includes a service cluster;

[0131] The registration center is also used to register information about each business instance in the business cluster;

[0132] The first target call control instance is also used to generate a call record between the first target agent and the first target user after synchronously recording the hang-up timestamp of the first target agent, and send the call record to the target service instance in the service cluster;

[0133] The target business instance is used to convert the call records into a new format and push the converted call records to an external business backend system through a preset interface.

[0134] In this embodiment of the application, a standardized link is constructed from call record generation to business system integration, and the specific process is as follows:

[0135] The registration center now includes information registration and maintenance for business clusters, recording information for each business instance, including instance IP address, service port, supported service types, current load status (such as CPU utilization and number of pending records), and interface adaptation capabilities. The registration center updates instance status in real time (e.g., automatically registering new instances and marking faulty instances as unavailable), providing accurate service discovery support for call control instances.

[0136] After recording the hang-up timestamp of the first-target agent, the first-target call control instance integrates all process data to generate a structured call log, including:

[0137] Basic identifiers: unique call ID, user number, agent ID, call type;

[0138] Time dimension: timestamps for each stage (call start, ringing, answering, hanging up), total call duration, and effective communication time;

[0139] Business dimension: Service type, network operator information, and call status (normal hang-up) in the outbound service request;

[0140] Related data: agent skill tags, user level tags (such as VIP).

[0141] Subsequently, the first target call control instance queries the real-time information of the business cluster through the registry center. Based on the business type matching degree (such as after-sales follow-up, the record is preferentially assigned to the instance that supports the type) and the load balancing (selecting idle instance) principle, the target business instance is determined and the call record is sent.

[0142] After the target service instance receives the call records, it performs the following operations:

[0143] Format adaptation: Convert the internal system format to the format required by the external business backend system according to preset rules, including field mapping, time format conversion, and structure reorganization;

[0144] Processing: Further desensitize sensitive information and supplement the metadata required by external systems (such as push system identifier and data verification code).

[0145] Push: Push the converted records to the external business backend system through the preset interface and receive confirmation receipt (such as API response 200 OK, message queue ACK) to ensure that the data is not lost; if the push fails, trigger the retry mechanism (according to the exponential backoff strategy).

[0146] Based on the above description, the unified registration and status monitoring of the business cluster by the registration center enables the call control instance to dynamically discover available business instances and accurately allocate tasks based on real-time load and business adaptability, avoiding overload of a single instance and improving the overall efficiency of call record processing; at the same time, it automatically switches to a healthy node when a business instance fails, ensuring the continuity of data flow.

[0147] The format conversion function of the target business instance shields the format differences between the call system and the external business backend system. Through configurable conversion rules, it can quickly connect to external systems without modifying the core call system, solving the high cost problem of one-system-one-development in traditional integration.

[0148] Furthermore, the call records contain full-link timestamps and business attributes, and after conversion, they still retain analytical dimensions (such as call duration and business type), providing complete data support for external systems. At the same time, the anonymization process and push receipt mechanism meet data security regulatory requirements and reduce compliance risks.

[0149] Furthermore, the business cluster adopts a distributed deployment, combined with the dynamic scaling support of the registration center, which can flexibly add instances as the call volume increases (new instances are automatically registered and take on tasks), and can complete the scaling without service interruption, supporting the large-scale call record processing needs in high-concurrency scenarios.

[0150] Figure 2 This diagram illustrates the interaction flow of an outgoing call scenario in a call system. (Refer to...) Figure 2 The outgoing call process of the call system may include the following steps:

[0151] The business front-end interface acts as the process initiator. The agent triggers the outbound call operation, calls the SDK's outbound call method, and sends an outbound call request containing the called number, line code, and extended data to the load balancer.

[0152] After receiving the request, the load balancer forwards it to the first target call control instance.

[0153] The first target call control instance creates an agent outbound call, selects a media server, executes the business outbound call logic, and after completing local initialization, asynchronously calls the first target media server instance and returns the call ID (used to uniquely identify the call across the entire link). The call ID is synchronized to the business front-end interface via the load balancer.

[0154] The first target media server instance sends a SIP INVITE signal (requiring the agent to answer automatically) to the first target SIP registration server instance, carrying the agent identifier and initial media negotiation parameters.

[0155] The first target SIP registration server instance queries the agent registration location and routes the INVITE to the first target protocol conversion gateway instance.

[0156] The first target protocol conversion gateway instance converts SIP signaling into a protocol that the agent front-end can recognize (such as WebSocket), and forwards it to the business front-end interface through the load balancer, triggering the agent to ring.

[0157] After the business front-end interface (agent terminal) recognizes the automatic connection mark, it automatically responds and collects media parameters (generating SDP), and returns SIP 183 (session progress) and SIP200 OK (session accepted) in sequence. The SIP parameters are then sent back to the first target media server instance through the first target protocol conversion gateway instance and the first target SIP registration server instance.

[0158] The first target call control instance publishes call start event, ringing event, and answer event to the business front-end interface, and asynchronously updates the call start time, ringing time, and answer time on the agent side.

[0159] The first target media server instance sends a SIP INVITE signaling message (inviting the user terminal to establish a session) to the first target call gateway instance, carrying the user number and media parameters.

[0160] The first target call gateway instance converts SIP signaling into a protocol supported by the line provider, routes it to the line provider, and triggers the user terminal to ring. The line provider initiates a call to the user terminal, and after the user answers, a SIP 200 OK response is returned, which is then transmitted back to the first target media server instance via the call gateway.

[0161] Two-way media stream establishment: The first target media server instance, based on the media negotiation results between the agent and the user (such as a unified codec format), bridges the media stream channels of both parties, realizing two-way audio and video transmission from the agent to the media server and from the media server to the user. At the same time, it publishes user call start event, ringing event, answer event, and synchronizes the call start time, ringing time, and answer time on the user side.

[0162] Call termination and resource release: Either the agent or the user initiates a hang-up (e.g., agent operation or user terminal hang-up), sends a SIP BYE signaling message, which is transmitted back to the first target media server instance via the corresponding link; the media server releases media resources, publishes a hang-up event to the first target call control instance, and asynchronously updates the call hang-up time on both the agent and user sides.

[0163] Call log archiving: The first target call control instance publishes a call end event for the agent. After the target business instance consumes this event, it converts the format of the call log and pushes the call log to the business backend system through an interface call to complete the persistent storage of data.

[0164] The above content describes the outgoing call request of the call system; the following content describes the incoming call request of the call system.

[0165] In an optional embodiment, the second target call gateway instance is further configured to receive the incoming call signaling of the second target user forwarded by the external line operator, and determine the second target media server instance in the media server cluster based on the status information of each media server instance in the media server cluster, and route the incoming call signaling to the second target media server instance.

[0166] The second target media server instance is used to publish an incoming call event to the second target call control instance in the call control cluster based on the incoming call signaling;

[0167] The second target call control instance is used to respond to the incoming line event, determine the second target agent, and send a call to the second target agent signaling to the second target media server instance;

[0168] The second target media server instance is also used to forward the call second target agent signaling to the SIP registration server;

[0169] The SIP registration server is used to route the call signaling to the second target agent to the second target protocol gateway instance in the protocol conversion gateway cluster based on the registration location information of the second target agent.

[0170] The second target protocol gateway instance is used to convert the second target agent signaling into a protocol recognizable by the second front-end interactive interface, and to route the converted signaling to the load balancer;

[0171] The load balancer is used to route the converted signaling to the second target front-end interactive interface based on the identifier of the second target agent, so as to trigger the second agent to ring the alarm.

[0172] In this embodiment, the second target call gateway instance receives incoming call signaling (including user number, call time, line type, etc., and the protocol format is the type supported by the line provider) from an external line provider forwarding the second target user's call. Based on the status information of each instance in the media server cluster synchronized by the registration center (such as load rate, media resource availability, and supported encoding / decoding capabilities), the target call gateway instance selects a second target media server instance with low load and sufficient resources, converts the incoming call signaling into a system-compatible format, and routes it to that second target media server instance.

[0173] The second target media server instance parses the incoming call signaling, extracts the information of the second target user (such as number, location, and historical incoming call tags), generates an incoming call event (carrying the user identifier, incoming call signaling reception time, and media server instance ID), and publishes the event to the healthy second target call control instance in the call control cluster.

[0174] Subsequently, the second target call control instance responds to the incoming call event, determines the second target agent from the agent resource pool based on the preset allocation strategy (such as the matching degree between user service tags and agent skill tags, agent idle status, and historical service correlation), generates a call signaling message for the second target agent (including agent identifier, user information, and media negotiation initial parameters), and sends it to the second target media server instance.

[0175] The second target media server instance forwards the signaling for the second target agent to the SIP registration server cluster. The SIP registration server queries the locally stored second target agent registration location information (i.e., the address, port, and protocol type of the protocol conversion gateway instance bound when the agent logs in), matches the corresponding second target protocol gateway instance from the protocol conversion gateway cluster, and routes the signaling to that instance.

[0176] After receiving SIP-formatted agent call signaling, the second target protocol gateway instance converts it into a protocol (such as the WebSocket protocol) that can be recognized by the second front-end interactive interface (agent terminal, such as a web browser), ensuring that the front end can parse the signaling content.

[0177] The converted signaling is sent to the load balancer. Based on the second target agent identifier carried in the signaling, the load balancer queries the registry center for the binding relationship between the agent and the front-end interface (ensuring routing to the second user's currently logged-in front-end interface of that agent), and forwards the signaling to the second target front-end interface. Upon receiving the signaling, the second user's front-end interface immediately triggers a ringing alert (such as an interface pop-up, ringtone notification, or agent status switching to "ringing") to notify the second target agent of a new incoming call.

[0178] Based on the above description, the second target call gateway instance selects the instance based on the real-time status of the second target media server instance to avoid forwarding signaling to overloaded nodes and reduce signaling processing delays; the second target call control instance determines the second target agent through label matching and status detection to ensure that incoming calls are quickly assigned to suitable available agents, shortening user waiting time and improving call connection efficiency.

[0179] Furthermore, the second target protocol gateway instance implements the conversion between SIP (system internal protocol) and WebSocket (web front-end protocol), enabling the second target agent to access the system through lightweight terminals such as browsers and mobile apps, breaking through the hardware limitations of traditional handsets, expanding the adaptability of agent terminals, and improving system flexibility.

[0180] Furthermore, in this application embodiment, all components (gateway, media server, call control, protocol gateway) are based on clustered deployment and status monitoring of the registration center. When a certain instance fails, the signaling can be automatically routed to a healthy instance (e.g., when the media server fails, the gateway switches to another instance, and when the agent terminal is offline, the call control reassigns agents), avoiding single point failures that cause call interruption and improving the overall availability of the system.

[0181] Optionally, the second target front-end interactive interface is also used to, after triggering the second agent's ringing reminder, respond to the second target agent's answering operation, trigger the second agent's answering event, generate the second target agent's answering response signaling, and return the second target agent's answering response signaling to the second target media server instance through the second target protocol conversion gateway instance;

[0182] The second target media server instance is used to publish a second agent connection event to the second target call control instance according to the second target agent answer response signaling, update the corresponding call data, and establish a bidirectional media stream transmission channel between the second target user and the second target agent.

[0183] In this embodiment, a complete closed loop from agent operation to two-way call connection is achieved, and the specific steps are as follows:

[0184] After the second target's front-end interactive interface triggers a ringing reminder for the second agent (e.g., a pop-up window or notification tone), when the second target agent performs an answer operation (e.g., clicking the answer button on the interface), the front-end interface immediately triggers a second agent answer event (recording the agent's operation time and identifier) ​​and generates a second target agent answer response signaling. This second target agent answer response signaling includes the agent identifier, answer operation time, and agent terminal media capabilities. It is forwarded through the second target protocol gateway instance to the second target protocol gateway instance, which converts the front-end interface's protocol format into a system-compatible signaling format (e.g., SIP200 OK). Finally, the converted response signaling is sent to the second target media server instance.

[0185] After receiving the second target agent's answer response signaling, the second target media server instance parses the agent's answering status and terminal media parameters, and performs the following operations:

[0186] The second target call control instance publishes a second agent connection event, which carries the agent identifier, the time of receiving the answer response signaling, the agent terminal media capability summary, and synchronizes the key status of the agent having answered the call.

[0187] Update local call data records, including agent answer timestamp, initial media negotiation parameters (such as codec formats supported by the agent), and current call stage (from ringing to waiting for media stream establishment).

[0188] The second target media server instance, based on the agent terminal's media capabilities, negotiates media parameters using the media parameters of the second target user's terminal (such as the audio codecs supported by the user's mobile phone) previously obtained from the target call gateway instance. After negotiation, the media server establishes media stream transmission links with the second target user's terminal and the front-end interactive interface of the second target agent, respectively, and bridges the two links to form a bidirectional media stream transmission channel from the second target user, the second target media server, to the second target agent, enabling real-time interaction of audio and video data between the two parties (such as the user's voice being transmitted to the agent through the channel, and the agent's voice being synchronously fed back to the user).

[0189] Based on the above description, this application embodiment provides a full-link response from the second target agent clicking to answer to the establishment of a bidirectional stream on the second target media server instance, ensuring that the second target user and the second target agent can start communicating the moment the call is answered, avoiding silent waiting caused by system delays, and improving the naturalness of the call and user experience.

[0190] Furthermore, the second agent's call connection event is synchronized to the second target call control instance through the second target media server instance, ensuring that the second target call control instance, the second target media server instance, the second front-end interactive interface, and other components have a consistent understanding of the second target agent's answered status, thus avoiding anomalies caused by asynchronous status.

[0191] The second target media server instance negotiates parameters based on the media capabilities of both terminals and transmits audio and video data through an independent bidirectional channel, reducing stuttering and noise caused by parameter mismatch. At the same time, the second target media server instance can monitor the streaming status (such as packet loss rate) in real time, providing data support for subsequent quality optimization.

[0192] In one alternative implementation, the second target call control instance is specifically used for:

[0193] In response to the incoming line event, the system determines the interactive voice response instruction to be executed based on the tag of the second target user, and sends the interactive voice response instruction to the second target media server instance.

[0194] In response to the interactive voice response broadcast end event returned by the second target media server instance, the status of each agent in the agent cluster is detected:

[0195] If all agents are busy, the incoming call signaling of the second target user is stored in the waiting queue, and a waiting audio instruction to be executed is generated and sent to the second target media server instance.

[0196] If an available agent exists, the second target user is bound to the optimal available agent based on the matching degree between the agent's skill tag and the business tag of the second target user, and the agent's current load. The signaling to call the second target agent is then sent to the second target media server instance; wherein, the optimal available agent is the second target agent.

[0197] In this embodiment, after the second target call control instance responds to the incoming call event, it first parses the second target user tag (such as user service tag, user level, historical interaction tag) carried in the event, and determines the interactive voice response command to be executed based on the tag matching preset service rules. For example:

[0198] If the user's tag includes "Bill Inquiry", the IVR (Interactive Voice Response) command is to play the voice prompt "Please enter the inquiry password" followed by the # key, and the user's input is collected.

[0199] If the user is a VIP, the IVR command skips the basic navigation and directly plays the voice message that you are being transferred to a dedicated agent and to please wait. Subsequently, the call control instance sends the IVR command (including the voice file identifier and interaction logic such as key capture rules) to the second target media server instance, driving the media server to execute voice playback and interact with the user.

[0200] When the second target media server instance completes the IVR voice broadcast (e.g., the user completes key input or the IVR process ends naturally), it returns an interactive voice response broadcast end event to the second target call control instance (carrying the user's IVR interaction result, such as the user selecting the bill inquiry service). The call control instance responds to this event by querying the real-time status of all agents in the agent cluster (online / offline, idle / busy, current call count, etc.) through the registry center, handling it in two ways:

[0201] If all agents are busy: the call control instance stores the incoming call signaling of the second target user into the waiting queue, which is sorted and managed according to user level and waiting time; at the same time, it generates a waiting audio instruction and sends it to the second target media server instance, which plays the waiting audio to the user terminal to prevent the user from hanging up due to lack of response.

[0202] If an available agent is available, the call control instance selects the best available agent (i.e., the second target agent) based on the following rules:

[0203] Skill tag matching score: calculate the matching score between the agent's skill tag and the business tag of the second target user (e.g., 10 points for a complete match and 5 points for a partial match).

[0204] The current load of the agent is calculated by counting the number of calls currently being processed by the agent (e.g., 0 calls are idle, 1 call is low load, and 2 or more calls are medium to high load). The lower the load, the higher the weight.

[0205] The system performs a comprehensive ranking, calculates a combined score based on matching degree and load weight, selects the available agent with the highest score as the second target agent, and binds the user to that agent. Finally, the call control instance sends a call signaling message (including agent identifier and user IVR interaction result) to the second target media server instance, triggering the subsequent agent ringing process.

[0206] Based on the above description, the embodiments of this application trigger targeted IVR commands based on user tags, reducing the cost of confirming basic information of human agents; at the same time, the standardized execution of the IVR process (such as unified voice prompts and keypad rules) ensures that different users receive a consistent service entry experience, avoiding service non-standardization caused by differences in agent scripts.

[0207] Furthermore, when screening available seats, skill tag matching is prioritized to ensure user needs are met, and seats with expertise in that business are assigned to handle the calls, reducing transfer rates and communication costs. Current load considerations prevent overloading of any single seat, balance cluster resource utilization, and reduce the risk of call delays.

[0208] Queue management and waiting audio playback when all agents are busy can reduce the rate of users hanging up directly and improve the call connection rate; at the same time, personalized waiting audio can reduce users' waiting anxiety.

[0209] Furthermore, both IVR commands and agent allocation rules are dynamically generated based on user tags and business rules, and can be quickly adapted to new business scenarios without modifying the core code through configuration adjustments.

[0210] As a concrete example, Figure 3 This diagram illustrates the interaction flow of an inbound call scenario in a call system. (Refer to...) Figure 3 The process of receiving a call from a call system may include the following steps:

[0211] After a user dials a number, the line provider routes the incoming call request to a second target call gateway instance, where the SIPINVITE signaling contains the user's number and the called number.

[0212] After receiving the signaling, the second target call gateway instance selects a second target media server instance (based on load and availability policies) and forwards the INVITE signaling to the second target media server instance.

[0213] The second target media server instance publishes an incoming line event (including user number, called number, and other information) to the second target call control instance.

[0214] The second target call control instance asynchronously processes incoming line events and executes the following logic.

[0215] IVR process matching: Match the incoming line route based on the called number and find the IVR (Interactive Voice Response) routing rule to be executed (e.g., press 1 to transfer to a human operator, press 2 to check the bill).

[0216] Execute the IVR process: trigger the broadcast of a welcome message (such as "Welcome to XX Customer Service Center"), and send a broadcast command to the second target media server instance; after the media server executes the voice broadcast, it updates the execution log and publishes a broadcast end event.

[0217] If all seats are busy, the system will perform an enqueue operation, sending a command to the media server to loop the waiting music, and simultaneously updating the queue record.

[0218] Seat allocation: When there is an available seat in the queue, the second target call control instance performs dequeueing, generates a pairing task, executes the pairing task, and sends a SIP INVITE signaling (call target seat) to the second target media server instance.

[0219] The second target media server instance forwards the INVITE signaling to the second target SIP registration server instance, which then routes the INVITE signaling to the second target protocol conversion gateway instance based on the agent's registration location.

[0220] The second target protocol conversion gateway instance converts SIP signaling into a protocol that the agent front-end can recognize (such as WebSocket), and forwards it to the business front-end interactive interface via the load balancer.

[0221] The SDK of the business front-end interface processes the incoming call event and triggers the agent to ring; after the agent performs the answering operation, it returns a SIP200 OK response, which is transmitted back to the second target media server instance through the second target protocol conversion gateway instance and the second target SIP registration server instance.

[0222] The second target media server instance publishes an connection event to the second target call control instance.

[0223] The second target call control instance updates the queuing and call data, triggering the second target media server instance to bridge the bidirectional media stream channel from the user to the second target media server instance and from the agent to the second target media server instance, and the two parties begin the call.

[0224] Reference Figure 4 The diagram illustrates the specific structure of a call system. The call system includes:

[0225] Line providers are external communication network providers responsible for call access and routing for user terminals.

[0226] A call gateway instance is used to connect to line providers, realize the conversion between external protocols and the system's internal SIP protocol, and act as a bridge between the call system and the external network.

[0227] The media server cluster is the core of media processing, containing multiple media server instances (Instance 1~4), responsible for SIP signaling forwarding, media stream bridging, audio and video encoding and decoding, etc.

[0228] The call control instance is the core of the business logic and contains multiple call control instances (Instance 1~2), which are responsible for call initiation / access, agent allocation, IVR process, event synchronization, etc.

[0229] Business instances are used to handle business logic extensions (such as call record storage and CRM integration), and contain multiple business instances (Instance 1~2).

[0230] The registry center, as the core of service governance, contains multiple registry center instances (1~3), which are responsible for registering the status (online / offline, load) of each instance in the cluster and providing service discovery capabilities.

[0231] This protocol conversion gateway instance is used to convert between the SIP protocol and the agent front-end protocol (such as WebSocket), adapting to lightweight terminals such as web agents and mobile devices.

[0232] A load balancer (LB) is a traffic distribution device that uses strategies such as round-robin, weighting, and least connections to distribute requests to backend cluster instances, thus avoiding single-point overload.

[0233] A workstation is the access terminal for customer service personnel (such as a web-based workstation interface or a hardware phone), which interacts with the system through a protocol conversion gateway.

[0234] Based on this call system, the process of a user making an inbound call is as follows: the user dials a number, the line provider routes the inbound call request to the call gateway instance, the call gateway converts the external protocol to SIP, forwards it to the media server cluster, and triggers the subsequent call control and agent allocation process.

[0235] The process of an agent making an outbound call is as follows: the agent initiates an outbound call through the front-end interface, the request is forwarded to the call control instance via the protocol conversion gateway instance and the load balancer, the call control schedules the media server, and the media server initiates a user-side call through the call gateway instance and the line provider.

[0236] Service registration and discovery: Cluster instances such as media servers, call control, and business instances register their own status (such as load and service capabilities) with the registry center; when a component needs to call other services (such as call control calling a media server), it queries available instances through the registry center to achieve dynamic service discovery.

[0237] In this system, core components such as media servers, call control, and the registry center are all deployed using a multi-instance cluster. When one instance fails, the load balancer automatically switches traffic to other healthy instances, avoiding service interruptions caused by single points of failure and ensuring system availability. The registry center centrally manages the service status of each instance and supports dynamic scaling of instances (e.g., when adding a media server instance during peak business periods, the registry center automatically identifies and handles the traffic), completing resource adjustments without service downtime and improving system elasticity.

[0238] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A calling system, characterized in that, The system includes: a call control cluster, a media server cluster, a load balancer, and a registry center; The registration center is used to register information about each cluster in the call control cluster and each cluster in the media server cluster; The load balancer is used to respond to outbound service requests sent by the front-end interactive interface and allocate the outbound service requests to a first target call control instance in the call control cluster; wherein, the first target call control instance is a call control instance in the call control cluster that is in an online state. The first target call control instance is used to determine a first target media server instance in the media server cluster based on the status information of each media server instance in the media server cluster in the registration center, and send a target call instruction to the first target media server instance based on the outgoing call service request. The first target media server instance is used to establish a bidirectional media stream transmission channel between the first target user and the first target agent in the outgoing service request based on the media parameters in the target call instruction. The outbound service request is generated by the first target agent after performing a specific operation on the first front-end interactive interface; wherein, the outbound service request includes the information of the first target user, the identifier of the first target agent, and the service type; The system also includes a SIP registration server cluster and a protocol conversion gateway cluster; The registration center is also used to register information about each cluster in the SIP registration server cluster and each cluster in the protocol conversion gateway cluster. The first target media server instance is further configured to generate a first call signaling for the first target agent according to the target call instruction, and send the first call signaling to the first target SIP registration server instance in the SIP registration server cluster; The first target SIP registration server instance is used to determine the first target protocol conversion gateway instance in the protocol conversion gateway cluster based on the registration status information and registration location of the first target agent, and to route the first call signaling to the first target protocol conversion gateway instance; The first target protocol conversion gateway instance is used to convert the first call signaling into a protocol recognizable by the first front-end interactive interface, and forward the first call signaling after protocol conversion to the first front-end interactive interface; The first front-end interactive interface is used to automatically respond to the first call signaling after the protocol conversion, start collecting the audio and video information of the first target agent, generate target media parameters, and return the target media parameters to the first target media server instance through the first target protocol conversion gateway and the first target SIP registration server instance. The first target media server instance is further configured to establish a first media stream transmission sub-channel with the first front-end interactive interface based on the target media parameters. The first media stream transmission sub-channel is used to transmit the audio and video data of the first target agent.

2. The system according to claim 1, characterized in that, The first target media server instance is also used for: After generating the first call signaling, a seat call start event is sent to the first target call control instance; The first target protocol conversion gateway instance is used to forward the converted call instruction to the first front-end interactive interface, and after the first front-end interactive interface enters the agent ringing state, it sends an agent ringing event to the first target call control instance. Upon receiving the target media parameters, a seat answering event is sent to the first target call control instance; When a media stream transmission channel is established with the first front-end interactive interface, a user call start event is sent to the first target call control instance; wherein, the user call start event is used to indicate that the audio and video media streams between the first target agent and the first target user have started bidirectional transmission. The first target call control instance is also used for: In response to the agent call start event, the call start timestamp of the first target agent is recorded synchronously; In response to the seat ringing event, the ringing timestamp of the first target seat is recorded synchronously; In response to the seat answering event, the answering timestamp of the first target seat is recorded synchronously; In response to the user call start event, the call start timestamp for the first target user is recorded synchronously.

3. The system according to claim 1, characterized in that, The system also includes a call gateway cluster; The first target call control instance is further configured to determine the first target call gateway instance in the call gateway cluster based on the attribute information of the first target user in the outgoing call service request, and in combination with the load status and line adaptability of each call gateway instance in the call gateway cluster. The first target media server instance is further configured to generate a second call signaling for the first target user according to the target call instruction, and send the second call signaling to the first target call gateway instance; The first target call gateway instance is used to convert the second call signaling to a protocol format supported by the external line operator, and to route the protocol-converted second call signaling to the external line operator to request the external line operator to initiate a call to the first target user.

4. The system according to claim 3, characterized in that, The first target call gateway instance is also used to receive the ringing response returned by the external line operator and return the ringing response to the first target media server instance; The first target media server instance is also configured to send a user ringing event to the first target call control instance after receiving the ringing response; In response to the user ringing event, the first target call control instance synchronously records the ringing timestamp of the first target user and publishes the ringing event of the first target user to the load balancer. The load balancer is used to forward the ringing event of the first target user to the first front-end interactive interface; The first front-end interactive interface is used to send the ringing event of the first target user to the first target agent.

5. The system according to claim 4, characterized in that, The first target call gateway instance is also used to receive the answer response returned by the external line operator and return the answer response to the first target media server instance; The first target media server instance is also configured to send a user answer event to the first target call control instance after receiving the answer response; In response to the user answering event, the first target call control instance synchronously records the first target user's answer timestamp and publishes the first target user's answering event to the load balancer. The load balancer is used to forward the answering event of the first target user to the first front-end interactive interface; The first front-end interactive interface is used to publish the call answering event of the first target user to the first target agent.

6. The system according to claim 3, characterized in that, The first target call gateway instance is also configured to receive the user call termination response returned by the external line operator, and return the user call termination response to the first target media server instance; The first target media server instance is also configured to send a user hang-up event to the first target call control instance after receiving the user call termination response; The first target call control instance is also configured to respond to the user hang-up event by synchronously recording the hang-up timestamp of the first target user and publishing the hang-up event of the first target user to the load balancer; The load balancer is also used to forward the hang-up event of the first target user to the first front-end interactive interface; The first front-end interactive interface is also used to send the hang-up event of the first target user to the first target agent.

7. The system according to claim 3, characterized in that, The first target media server instance is further configured to terminate the media stream transmission with the first target agent after receiving the first target agent hang-up instruction forwarded by the first front-end interactive interface, generate a first target agent hang-up event, and publish the first target agent hang-up event to the first target call control instance. The first target call control instance is also used to synchronously record the hang-up timestamp of the first target agent in response to the hang-up event of the first target agent.

8. The system according to claim 7, characterized in that, The system also includes a service cluster; The first target call control instance is also used to generate a call record between the first target agent and the first target user after synchronously recording the hang-up timestamp of the first target agent, and send the call record to the target service instance in the service cluster; The target business instance is used to convert the call records into a new format and push the converted call records to an external business backend system through a preset interface.

9. The system according to any one of claims 3-8, characterized in that, The second target call gateway instance in the call gateway cluster is used to receive the incoming call signaling of the second target user forwarded by the external line operator, and based on the status information of each media server instance in the media server cluster, determine the second target media server instance in the media server cluster and route the incoming call signaling to the second target media server instance. The second target media server instance is used to publish an incoming call event to the second target call control instance in the call control cluster based on the incoming call signaling; The second target call control instance is used to respond to the incoming line event, determine the second target agent, and send a call to the second target agent signaling to the second target media server instance; The second target media server instance is also used to forward the call second target agent signaling to the SIP registration server; The SIP registration server is used to route the call signaling to the second target agent to the second target protocol gateway instance in the protocol conversion gateway cluster based on the registration location information of the second target agent. The second target protocol gateway instance is used to convert the second target agent signaling into a protocol recognizable by the second front-end interactive interface, and to route the converted signaling to the load balancer; The load balancer is used to route the converted signaling to the second target front-end interactive interface corresponding to the second target agent based on the identifier of the second target agent, so as to trigger the second agent to ring and remind.

10. The system according to claim 9, characterized in that, The second target front-end interactive interface is also used to respond to the answering operation of the second target agent after the second agent ringing reminder is triggered, trigger the second agent answering event, generate the second target agent answering response signaling, and return the second target agent answering response signaling to the second target media server instance through the second target protocol conversion gateway instance in the protocol conversion gateway cluster; The second target media server instance is used to publish a second agent connection event to the second target call control instance according to the second target agent answer response signaling, update the corresponding call data, and establish a bidirectional media stream transmission channel between the second target user and the second target agent.

11. The system according to claim 9, characterized in that, The second target call control instance is specifically used for: In response to the incoming line event, the system determines the interactive voice response instruction to be executed based on the tag of the second target user, and sends the interactive voice response instruction to the second target media server instance. In response to the interactive voice response broadcast end event returned by the second target media server instance, the status of each agent in the agent cluster is detected: If all agents are busy, the incoming call signaling of the second target user is stored in the waiting queue, and a waiting audio instruction to be executed is generated and sent to the second target media server instance. If an available agent exists, the second target user is bound to the optimal available agent based on the matching degree between the agent's skill tag and the business tag of the second target user, and the agent's current load. The signaling to call the second target agent is then sent to the second target media server instance; wherein, the optimal available agent is the second target agent.

Images