Chapter 1: Input Data

Prerequisites for the creation of the platform «Incoplax»

* * Increased number of requests for communication solutions from large organizations that cannot be satisfied with a single server solution (up to 1000 subscribers). * Increase in the number of requests for UC (unified communications) products, organization of omni-channel services, VCS. * Over a couple of decades, a number of companies have consolidated and mostly spontaneously automated. As a result, large amounts of assorted hardware and software responsible for communications have accumulated. They "somehow" work, having been once customized by someone, but they are not supported or supported with insufficient quality and have no possibility to be adapted to new tasks. Several pieces of equipment are known to fail every day. In large companies, where one-step replacement is impossible, but communication is a strategic resource, it is a kind of roulette. Such a tangible asset is managed by armies of administrators spread across the country with disparate knowledge. Such assets include products of companies that have left the domestic market. * Mass rejection of Western solutions in favor of freely distributed software. * Technology advances are accelerating, communications are increasingly becoming the backbone of operations and penetrating deep into business processes, increasingly integrated with other tools.

What is required is a solution that is ready for functional development, whose architecture allows to combine the results of different teams working in different technologies and at different speeds without loss of manageability and structure, that scales horizontally to the size of 1,000,000+ subscribers and users.

Main tasks of the platform «Incoplax»

  • A server-based distributed platform for telephony and related business tasks (call center, Omni, UC, etc.) solved on its basis.

  • Allows you to serve a large number of geographically distributed corporate divisions with large requirements for fault tolerance.

  • Supports separation into multiple independent companies with independent data management, served on the same physical infrastructure.

  • Can integrate with and be used from arbitrary CRMs as a communications enablement environment.

  • It is configured, monitored and managed through an open API, gradually acquiring its own client application running through the same API API.

  • Supports telephone services familiar to the large sector.

  • Manageable scale 1000+. Techniques for scaling up.

  • Manageable accessibility 99,(9)%. Techniques to increase accessibility.

  • Spread across geographically distributed sites with preservation of their operability in case of network unavailability.

  • Ability to split and merge control point (one admin for all, or each domain has a separate admin).

  • Support for embedding in other products.

  • Possibility of functional expansion in the corporate direction, SaaS, PaaS.

  • No-Code and Low-Code tools to create information systems seamlessly linked to communication processes.

  • No-Code and Low-Code tools for creating scenarios: service, business processes, data exchange, ETL.

  • RAD-information and communication systems designer.

Requirements

Basic functional requirements

  • Full protocol support SIP.

  • Register phones under user accounts.

  • User-to-user calls, holds, transfers, intercepts.

  • A second incoming call when you have an active call.

  • Redial to the number of the previous caller.

  • Connection to external PBXs and providers with and without registration with the ability to swap numbers.

  • Conference call on the phone.

  • Server conference room (>100 subscribers).

  • Conference calls with voting (>100 subscribers).

  • IVR-voice call service scenarios with support for speech recognition and synthesis.

  • Data management via API.

  • Monitoring activity and availability through API.

  • Two-step rule-based call routing with support for regular expressions, masks, table filters and modifiers.

  • Maintain logs on calls, scripts, and business logic.

  • Integration with LDAP.

  • Centralized Updates.

  • Group rooms.

  • Queue Support.

  • Multiple call support.

  • Saving telephony events and data, sending to broker.

  • Saving a record of conversations.

  • Softphone application support.

  • Softphone support in browsers.

  • Virtualization: multiple independent companies on the same infrastructure.

  • Mechanisms for notifying external systems of events.

  • Video calling support.

  • Call management via API.

  • Data model management with change subscriptions.

  • Support for various storage and protocols.

  • Mailbox Connection.

  • Connecting to messengers.

  • Automated service bots for text and voice channels.

  • Support and manage the availability of third-party microservices and web applications.

  • Sniffers from external networks receive no responses from the system and show no interest in it.

Non-functional requirements

Quality attributes are listed in descending order of priority - architecture drivers.

  • Scalability/extensibility

  • Availability/Reliability

  • Variability/Modifiability

  • Speed of development

  • Compliance with standards

  • Performance

  • Maintainability

  • Defense against attacks

  • Documented

  • Integratability

Selective scenarios to quality attributes

  • An arbitrary SIP phone is connected to the system in 2 minutes, is registered and has the ability to make and receive calls, hold, transfer.

  • When the server is randomly turned off, the subscriber dials a number and makes a successful call and connection to another subscriber.

  • When there are 1000 active conversations, the subscriber dials the number and connects to another subscriber.

  • If 200 cps is available, the subscriber dials the number and connects to another subscriber.

  • After any server shutdown, the phone remains registered and the account can be called without meaningful delays.

  • The system is deployed in Lisbon and Madrid. There is no communication between the cities. A subscriber in Madrid registers and calls another subscriber in Madrid. A subscriber in Lisbon registers and calls another subscriber in Lisbon.

  • After communication between the cities is restored, the subscriber in Lisbon dials the number of the Madrid subscriber and connects to him.

  • Administrator deploys the site in Novosibirsk in less than 1 hour if servers and deployment plan are available.

  • A support staff member identifies the cause of the server crash within an hour.

  • A support staff member identifies the reason for the failure to make the call within an hour.

  • The attacker tries for the 56th time to register or call under a non-existent account or with an incorrect password for 30 seconds. The system does not respond and blocks the IP address at the lower level for 20 minutes. The attacker’s subsequent requests are unanswered and create a tenfold lower load on the system’s server processors.

  • Administrators of two independent organizations agree, set up routes each in their workroom within 1 minute and make it possible to call users from the first to the second.

  • During a phone call, any server is turned off and the connection is not broken, sound is lost for no more than 1 second.

  • One server serves 200 simultaneous calls with no loss or latency at cps 10 per second.

  • The 201st user enters the conference in less than 3 seconds and hears the caller speaking, everyone can hear him too.

  • Programmer adds a new script component in less than 1 day.

  • Programmer adds a new script microservice in less than 1 day.

  • Arbitrary Web CRM system connects API system based on "Incoplax" in less than 1 week.

  • Admin adds 1 server to the cluster at the site and increases performance by 100 cps / 200 concurrent calls / 1000 BLFs per second / 1000 registrations per second.

  • During any server reboot, the subscriber places a call and makes a call with a delay of no more than 5 seconds.

  • During a telephone conversation, communication with external devices is lost. The conversation is terminated by the server forcibly within 2 hours, the record of the conversation ends up in the storage within 2 hours.

  • MVP application management systems or helpdesk is created in less than 8 hours.

  • MVP information system package based on an object model of 10 classes and 50 requirements is created in less than 20 hours.

  • A tabular report, a chart on aggregated data, a dashboard with indicators based on data in the object model can be created in 30 minutes.

More detailed scenarios to the quality attributes are formulated in the wiki.

Technical requirements

  • SIP/2.0 protocol support by UDP, TCP, TLS, WebSocket, WebSocket secure.

  • Support for RTP, DTLS (including for WebRTC).

  • HTTP, HTTPS, WebSocket API.

  • Supports the requirements of various SIP providers:

    • that require media traffic to be sent from the address of the connected device;

    • prohibiting REFER;

    • requiring requests to be sent from a single account;

    • limiting the number of simultaneous dialogs;

    • that require OPTIONS support or counter pings through the OPTIONS.

  • Support for a variety of SIP devices (i.e., focus on the most basic set of RFCs for SIP)

    • that do not support multi-codec matching;

    • that can’t work with NAT and spoof media-address-port spoofing in the SDP;

    • who don’t understand custom charsets;

    • who don’t know how to re-register upon request.

  • Support for broadband codecs (Speex, OPUS).

  • Support for voice codecs g.711a, g.711u, g.729ab, g722, g726, gsm610, iLBC.

  • Video codec support H.263, H.264, VP8/VP9.

  • Use of freely distributed PostgreSQL database, including the one installed at the customer’s premises.

  • Supports distribution to multiple sites.

  • Support independent operation of sites in case of lack of communication between them.

  • Architecture support x64.

  • Cross-platform: support for Linux, Windows, virtual machines VMWare, HyperV.

  • Support for multiprocessor systems (NUMA, etc.).

  • Support for delivery in a docker container.