Telephony, unified communications and contact centres
We design, develop and keep in production the agent side of a contact centre: custom WebRTC phone bars, states and queues, integrations with business software and help desks. We install and fix PBXs (Asterisk, also compiled from source, FreePBX, NethVoice, Yeastar), work on Cisco Unified CM through its APIs and look after telephony disaster recovery.
Our strongest point is diagnosis: dropped calls and instability reconstructed call by call from several cross-referenced sources, down to SIP and RTP captures. And one rule that does not change: new versions reach the workstations only when the client asks for them, after a pilot on one workstation.
WebRTC phone bars for agents
We develop on commission and maintain desktop phone bars that integrate with the web agent client of contact centre platforms: they drive its page and its SIP SDK, add the missing features and make blind and consultative transfers, hold and pauses reliable. They also work on older workstations and in VDI, dock to the edge of the screen and write a structured log for each workstation, which is the basis of every diagnosis.
Technologies and products
- Electron and Node.js
- Native C++ modules (N-API)
- JsSIP, WebRTC, SIP over secure WebSocket
- Cisco AXL
- SQL Server
- NDJSON logs
Examples
-
Contact centre in the distribution sector, a few dozen workstations In production
The phone bar a multi-site contact centre was missing
- The problem
- The platform’s standard web agent client was not enough: the microphone stayed blocked inside the page frame and call events were not accessible.
- What we did
- A bar with an isolated web view and deep integration with the platform. Over time it has added automatic forwarding from the physical phone to the virtual extension, the customer record on answer, call pickup from the queue (with counts identical to the native counters), supervisor-initiated pause and switchover to the disaster recovery site.
- Result
- In daily production use, with ongoing development in 2026.
-
Contact centre on VDI In production
A phone bar that started but was not visible
- The problem
- On some workstations the bar showed as running but did not appear on the screen.
- What we did
- The workstation log showed SIP registrations without a single click from the agent. The cause: a VDI image with desktop composition disabled, which does not draw transparent windows.
- Result
- The bar now opens opaque when composition is missing and notes this in the log.
Queues, ACD and outbound calls
We reconstruct the agent state machine (available, reserved, paused, talking, wrap-up, outbound) from the automatic call distributor’s protocol and from comparison with the original client application, and we fix collisions, unconfirmed pauses and reservations left hanging. On PBXs we choose queue strategies and timings to suit the workstations.
Technologies and products
- ACD commands and events over WebSocket
- Asterisk queues (rrmemory, ringall)
- Yeastar queues
- Asterisk AMI
- SQL Server
Examples
-
Contact centre in the distribution sector In production
Calls assigned to agents already on the phone, reduced by 97%
- The problem
- The automatic call distributor was assigning inbound calls to agents already busy on an outbound call.
- What we did
- By observing the protocol we saw that 88% of the collisions started from the paused state, because of a recovery mechanism in the bar, and that the command signalling “on outbound call” was missing before the call started. Two fixes, then measurement with a server-side observer independent of the bar.
- Result
- Overlaps fell from 23,600 a day, on the peak day, to 608: down 97%.
-
Contact centre in the distribution sector Delivered
Outbound calls dropping at exactly 90 seconds
- The problem
- Some outbound calls were always cut off after 90 seconds.
- What we did
- We tested and ruled out the session timer, phone and network leads, and demonstrated from the server logs that a timer that had not been reset was putting the agent back into the waiting state while the call was still in progress.
- Result
- Cause fixed and verified.
SBCs and WebRTC access for agents
We manage the SBCs that WebRTC agents connect to: registrations and reachability checks, kernel buffers, disk space, restarts. Our changes go through idempotent scripts that take a backup and stop if the result is not as expected.
Technologies and products
- Kamailio
- Asterisk with PJSIP
- coturn (STUN and TURN)
- WebRTC (ICE, DTLS-SRTP)
- podman, systemd, SELinux
Examples
-
Contact centre in the distribution sector In production
Two registrations per workstation where only one was allowed
- The problem
- Agent registrations were showing as “unreachable” in bursts (2,722 in 14 hours across 64 extensions), with audio interruptions.
- What we did
- We demonstrated, also with the official web client, that each workstation opens two SIP user agents on the same extension, while the configuration accepted only one. A pilot on two extensions, then roll-out to 112.
- Result
- Alerts reduced by 97% in 5-minute monitoring, audio interruptions down to zero, inbound calls verified with a SIP capture: no double ringing.
-
Contact centre in the distribution sector Delivered
A full disk on the disaster recovery SBC
- The problem
- The SBC at the disaster recovery site had a full disk.
- What we did
- We freed up space by removing 12 million rows from a debug log, without losing a single call record, and extended the disk online.
- Result
- Space recovered and a larger disk, without stopping the service.
Diagnosis of dropped calls and audio quality
We reconstruct each call by cross-referencing the workstation log, the application server and SBC logs and the PBX call detail records. In SIP and RTP captures there are always three questions: who ends the call, with what cause and whether the audio had already stopped.
Technologies and products
- SIP, RTP, Q.850 cause codes
- tcpdump and pcap
- Asterisk CDR and CEL
- Cisco CDR and PerfMon
- WebRTC statistics
Examples
-
Contact centre in the distribution sector Delivered
Two hundred and thirty “suspected dropped calls” a day, none due to the network
- The problem
- An indicator counted about 230 suspected dropped calls a day, 4.9% of the calls handled, and the network was thought to be the cause.
- What we did
- We reconstructed 147 cases one by one: all the repeat calls were new calls and none was a network drop. The causes were mainly three behaviours at the workstation: a microphone with no signal, hold pressed before the call connected, a double click on answer/hang-up.
- Result
- Measurements and safeguards added to the bar, to be enabled after a measurement period.
-
Contact centre in the distribution sector Delivered
Customers dropped while on hold, or perhaps not
- The problem
- It was estimated that about 200 customers a day were lost while on hold for a consultation.
- What we did
- We counted the real cases from the PBX event log.
- Result
- There were 7 in 14 days, out of 12,076 consultations: the first estimate also counted successful transfers.
-
Cisco installation with several trunks Delivered
A trunk that completed fewer calls than the others
- The problem
- Outbound calls were dropping a few seconds after being answered.
- What we did
- The PBX performance counters showed one trunk completing 77% of calls against 89% and 97% for the others; we ruled out the client software, the platform, the SBC and bandwidth control one by one.
- Result
- Cause traced to the telephone carrier and documented in a dossier.
Telephony disaster recovery
We design and test the switchover of telephony clients and servers to the disaster recovery site without touching DNS, with written restart and restore procedures.
Technologies and products
- Electron
- Flask
- coturn
- Asterisk FastAGI
- PowerShell and WinRM
Examples
-
Contact centre in the distribution sector In production
A switch to fail over to disaster recovery
- The problem
- In the event of a failure the workstations had to move to the DR site without reconfiguration and without touching DNS.
- What we did
- The bar reads the state from a portal and, if needed, remaps servers, STUN and database to the DR site under the same names, so the certificates remain valid; if the portal does not respond, it stays on production. During testing we found and fixed STUN and dialplan settings still tied to production, which were causing one-way audio.
- Result
- Switchover validated end to end for inbound calls, including the restart of the DR node (about 2 minutes of downtime).
-
Contact centre in the distribution sector In production
Orderly restart of the platform
- The problem
- Restarting the platform’s three servers without surprises for the agents.
- What we did
- A procedure covering database, SBC and web in that order, with 13 final checks.
- Result
- Carried out several times, including before the service opened, always successfully.
IP PBXs: Asterisk, FreePBX, NethVoice, Yeastar
We install Asterisk, including by compiling it from source, without a web interface and with version-controlled configuration; we analyse and fix FreePBX, PBXact and NethVoice installations; we install Yeastar P-Series on virtual servers and configure it through its APIs. Dialplan, IVR, queues, opening hours and public holidays, messages, basic security and data for statistics.
Technologies and products
- Asterisk 18 and 22, PJSIP
- FreePBX and PBXact
- NethVoice and NethServer
- Yeastar P-Series (OpenAPI)
- MariaDB and ODBC
- nftables and fail2ban
Examples
-
Support service for a public body Delivered
A PBX for a public-facing support service, compiled from source
- The problem
- A PBX was needed for 16 workstations on an operating system that no longer ships Asterisk.
- What we did
- Asterisk 22 compiled on Debian 13; IVR with an information notice, three round-robin queues with memory, public holidays up to 2035 in the PBX database, ten messages in the same synthetic voice, nftables and fail2ban, SQL triggers for the statistics dashboard already in use, documentation in 12 chapters.
- Result
- PBX delivered and tested with calls generated in the dialplan.
-
SME with a reception Delivered
The night-time message heard during the day
- The problem
- During the day, callers heard the night-time message.
- What we did
- We compared 31 daily backups of the PBX: 84 modules out of 88 identical, a single relevant change, with its date.
- Result
- Change identified and reverted.
-
SME with ten extensions Delivered
Outbound calls blocked by a route with no trunk
- The problem
- On a new PBX, outbound calls were not going out.
- What we did
- The route created by the setup wizard had no trunk assigned: we fixed it via the API. We ran the SIP diagnosis with tcpdump from the hypervisor, because direct access to the PBX was switched off.
- Result
- PBX in service with a queue, opening hours and a night-time message.
Cisco Unified CM, gateways and DECT
We work on Cisco Unified CM through AXL and PerfMon and integrate it with Asterisk and FreePBX using SIP trunks and dialplans. We change routing on Innovaphone federations and gateways and write tools that read from IP-DECT gateways.
Technologies and products
- Cisco Unified CM (AXL, PerfMon)
- SIP trunks and FreePBX
- Innovaphone
- Ascom IP-DECT
- Python
Examples
-
Contact centre in the distribution sector In production
Physical phone and virtual extension, without thinking about it
- The problem
- The agents had a Cisco phone on their desk and a virtual extension on the platform: calls had to reach the right place.
- What we did
- At login the bar sets forwarding of all calls to the virtual extension via AXL and removes it at logout, with automatic recovery after any abnormal shutdown.
- Result
- Forwarding always consistent with the agent’s state.
-
Group with several sites Delivered
Main numbers moved within a federation of PBXs
- The problem
- The main numbers of two sites had to reach the PBX at head office.
- What we did
- We changed the inbound routing maps, keeping the old rules as a fallback, saving the configurations before and after and documenting the rollback.
- Result
- Tested and working.
CTI integrations with business software and help desks
We connect telephone events to business systems: the customer record on answer, ticket creation, call outcomes recorded in a database, events from external contact centre platforms.
Technologies and products
- HTTP and SOAP
- SQL Server
- Electron
- .NET 8 and WebView2
- Flask-SocketIO
Examples
-
Healthcare booking call centre Delivered
Call outcomes, recorded at the end of each call
- The problem
- The end-of-call window, written years earlier, had to be rebuilt.
- What we did
- We rewrote it from C# WinForms to Electron: it shows the contact from the address book (about 8,300 entries), records one of seven outcomes in SQL Server with parameterised queries and updates itself.
- Result
- Tested on the real database.
-
Contact centre in the distribution sector In production
The customer record on answer
- The problem
- The customer record in the business software and in the help desk did not open after a call was picked up from the queue.
- What we did
- We fixed the defect and added the agent code and a filter for internal calls, then checked it live.
- Result
- The record opens on answer and on pickup from the queue.
Contact centre reports and metrics
We turn dashboards and call detail records into reliable reports and into “one row per call” tables built from several sources, documenting their pitfalls: time zones, log rotation, days with reduced load.
Technologies and products
- Excel and CSV
- MariaDB and SQL Server
- Python
One example
-
Group with several companies Delivered
Service level weighted by actual volumes
- The problem
- The daily per-queue dashboards did not give a reliable monthly measure.
- What we did
- We turned 132 daily dashboards, from October 2025 to February 2026, into a monthly report of calls handled and volume-weighted service level.
- Result
- A repeatable monthly report on tens of thousands of calls a month.
Presence and Microsoft unified communications
We administer Skype for Business Server and its coexistence with Teams; we read and write Teams presence through Microsoft Graph.
Technologies and products
- Skype for Business Server 2019
- Microsoft Teams
- Microsoft Graph and Entra ID
- PowerShell
Examples
-
Organisation with over a thousand users Delivered
Authentication pop-ups on every search, eliminated
- The problem
- Every contact search brought up authentication prompts, and one user could not sign in.
- What we did
- A missing attribute in Active Directory was blocking sign-in; the pop-ups came from the server’s OAuth authentication and from photos read from Exchange Online.
- Result
- Sign-in and searches without interruptions; we also documented the decision not to rebuild an integration based on retired technology.
-
Organisation with over a thousand users Delivered
External federation unblocked
- The problem
- Some users could not communicate with external organisations in Teams.
- What we did
- We traced the cause to the coexistence mode between Skype for Business and Teams.
- Result
- Two users moved to Teams Only mode, with a documented workaround.
Voice messages and out-of-hours calls
We produce PBX messages with neural speech synthesis, written for the 8 kHz telephone line, and we design automatic answering for when the switchboard is closed, bringing together technology, line sizing and rules (AI Act and GDPR).
Technologies and products
- Neural speech synthesis
- Asterisk (AudioSocket, ARI)
- Erlang B
One example
-
Support service open 49 hours a week Study
The seven ways to handle out-of-hours calls
- The problem
- The service was closed 119 hours out of 168 and out-of-hours calls were lost.
- What we did
- We compared seven options, from transcribed voicemail through an IVR linked to the business software to an AI voice assistant: a latency budget of 800 ms, lines sized with Erlang B, transparency obligations under the AI Act and the GDPR.
- Where we have got to
- Study delivered as a proposal.