Skip to content
Strategia Informatica
  1. Home
  2. Expertise
  3. Telephony and contact centres

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

  1. 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.
  2. 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

  1. 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%.
  2. 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

  1. 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.
  2. 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

  1. 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.
  2. 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.
  3. 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

  1. 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).
  2. 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

  1. 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.
  2. 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.
  3. 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

  1. 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.
  2. 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

  1. 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.
  2. 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

  1. 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

  1. 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.
  2. 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

  1. 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.

Tell us about the problem

A network to put back in order, an incident to handle, data to make sense of: the first conversation is about understanding whether and how we can help.