As part of her recruitment effortsAurore Masse, HR Manager, wanted to dig into the daily life of the XiVO development team.
What does the job of a XiVO Dev look like, in practice? What is the technical stack? Let's lift the lid, with this interview of Jirka Hlavacek, Lead tech / Head of Engineering at Wisper, to learn more about the back, front, environments, integration and deployment.
Can you start by briefly explaining the product?
Jirka: The XiVO platform adventure started about 15 years ago, with technologies and issues that are quite different from today's. XiVO offers unified communications services such as calls, video, chat; contact center services - interactive voice server, interface for agents and supervisors, call recording and qualification or statistics; and finally the platform can be integrated as a telecom engine for operational telephony projects such as help desk systems.
What environment do you work in?
Jirka: Our daily work is very diverse, the visible part of the iceberg are the web interfaces of our UC (for Unified Communications), administration and CC (for Contact Center) applications, including the integration of voice and video based on the WebRTC standard and APIs, all this with Typescript, TDD and Cypress tests to help us avoid bugs.
Our CTI backend is written in Scala with the Akka framework for robustness, still in TDD. The main database is PostgreSQL, but we also use ElasticSearch. The telecom engine of the platform is Asterisk, and most components are deployed in Docker.
Can you tell us more about the back-end tools?
Jirka: For all this to be possible, we need a configuration database, in our case PostgreSQL, and a web interface - this time partly in PHP, but currently being migrated to AngularJS. And then on the telecom engine side (Asterisk) some home-made patches so that the provisioning magic can work. And as Asterisk is mostly a toolbox, we also need scripts to check the provisioning code, the call rights and so on, this is the job of a Python daemon, xivo-agid. Outgoing calls, on the other hand, are managed via a more recent protocol, ARI, with an outcall module written in Scala.
I won't dwell on the call recording part, because apart from synchronizing the files between the switching servers and the storage and transcoding, it is of little interest. But without the metadata to search the recordings, the audio files are hardly usable.
So let's look at what we do to process the raw call events delivered by our Asterisk engine. These events are written locally to the PostgreSQL database, from where they are replicated to a dedicated machine for processing with a subset of the configuration needed to be able to produce activity reports. State machine-based data processing modules transform these events into lists of calls, transfers and other human-understandable objects, and then into aggregations to facilitate reporting. For contact centers, we also have real-time supervision panels, either using theKibana tool, or specific web pages based on the events available via a websocket proposed by the XUC server.
"XUC" server?
Only the veterans, one or two people remember the origin of the name - XiVO Unified Communications I think. This is our CTI server. It is written in TDD mode, API first, in Scala based on the AKKA framework, which took advantage of the Erlang language principle designed by Ericsson especially for telephone switchboards that have to "survive" all the errors. It's true that it never crashes, the bugs only impact subsystems (except in case of overload, where even AKKA can't work miracles).
Ok it's clear, thanks; what about the front end?
Jirka: Whether it's for the administration, management or piloting interfaces of the contact center, or applications offering voice or video communication services based on WebRTC technology, we rely on Typescript and AngularJS, always with TDD and CI.
A word about integration and deployment?
Jirka: Developments and fixes are produced by each developer in the branches to be reviewed and merged by another team member according to a "definition of done". All this is supported and supervised by Jenkins, our continuous integration engine. It also takes care of running daily install tests, and we also have load boards to identify memory leaks or other problems that are only visible in the long term. Call emulators like sipp help us a lot, but since we can't find an equivalent for WebRTC, we have our own call spawners and WebRTC recorders, since our platform has to support thousands of users and hundreds of concurrent calls.
For production we have adopted Docker since it started. It hasn't been easy at the beginning, but the tool has matured very quickly and makes our daily tasks easier.
"At the beginning": what were those beginnings?
At the time, the interconnection with ISDN networks was the Holy Grail, it involved both the issues of the Digium hardware driver and the configuration of the Asterisk telecom engine, which is the conductor. Our project has evolved a lot since then. We remain faithful to Open Source, but the problems we address today are very varied, which makes our days very rewarding... and sometimes very challenging!
XiVO is running on Debian, and the integration of the DHCP server that enables the provisioning of workstations and other services requires a deep integration with the OS. Moreover, when upgrading from one LTS (long-term support) to another, we automate the update of Debian as well - we have the honor to have loyal customers since the beginning, more than 10 years!
Once we have configured the OS - the right disk partitioning, NTP configuration, DNS and others - the provisioning part is waiting for us. A DHCP server, carefully configured to assign IP addresses to the terminals known by the system (MAC address prefixes help us with this), this same DHCP server pushes the necessary options to retrieve the configuration and firmware of the station. First in autoprovisioning, so that the user can become familiar with the stations, then via its provisioning code.
Is there anything you'd like to add, to make readers want to apply?
Jirka: There's a lot more to explore: call probes for load testing, ways to detect network issues that impact voice quality - you name it.
There are days when you'd like to stay in your comfort zone, but on this product you have to push yourself and sometimes go and solve a problem in an area where you're not good enough (yet). It's this never-ending curiosity, this taste for challenge, all within an Open Source project, that bring the team together so much - and people say we're a nice, self-organized and benevolent team. So let's meet!
Now that you know the Wisper Technical Stack, join our R&D teams and apply today
Learn more about the use cases of the XiVO solution with customer cases like Gédimat, SantéVet, Groupama or more like City of Lille and theUniversity of Lille.
