Transfer-Use Opensips and FreeSwitch to build a 10,000-level high-availability softswitch architecture

  Recently, due to project reasons, it is necessary to provide a softswitch server architecture that supports more than 10,000 levels and supports multiple applications. I made an adjustment to the previous architecture and wrote an article to summarize.

   The new architecture mainly solves the following problems:

A single set must support about 1w concurrent calls.
Fully high availability, no single point of failure.
Support multiple applications, such as outbound calls, incoming calls, and other voice-based communication applications.
Support multiple recording methods, at least two
  external to the entire platform In addition to the database, the only dependent services are Opensips and FreeSwitch. The overall architecture diagram is as follows:

   The overall design idea is as follows. The externally provided interface services or CTI interface services all use load balancing services, which can be implemented through F5, Nginx, or Haproxy, depending on specific requirements.

   Opensips with 8 cores and 16 can handle extension registration and call routing of more than 5w, because opensips does not do load balancing, it is master-slave;

   As a media server, freeswitch only handles media-related functions and provides call control functions. A single media server plus recording function can support 250 concurrent calls;

    Because other applications need to connect to the ESL of FreeSwitch, the concurrency is not unlimited, so clusters are also needed;

   The core design idea is to bind FreeSwitch and some CTI, ACD, IVR, OI (outbound interface) developed by itself and an FS together as a PBX unit. The core idea of ​​putting together is mainly that these can be used as the whole The basic unit of the communication capability platform, if one-to-many is the case, it is not easy to deal with the repetitive event;

   The core dispatch component is to distribute services. The main responsibility of the distribution service is to distribute requests to different computing units and to distribute events to the event processing source. The difficulty of the dispatch component is that the call is a continuous process. Ensure that all subsequent calls related to this are sent to the same computing unit.

  In the case of high-availability processing, if there is a problem with any service in a computing unit, the service will be automatically restarted first. If the restart fails, the computing unit will be set as unused and no new requests will be allocated, but it will not affect the current situation. Some call requests.
————————————————
Original link: https://blog.csdn.net/yugan7061/article/details/89679882

Guess you like

Origin blog.csdn.net/gredn/article/details/104940632