Five segments on the path of a call
A call crosses five segments before it reaches the other side, and only one of them is the PBX. ILS Networks designs, builds and maintains Asterisk and FreePBX systems together with the network layer they run on.
Overview
ILS Networks builds enterprise phone systems and operates them over time — including call-flow design, connection to the trunk provider, and tuning the network underneath so voice is prioritised rather than competing for the same traffic. We design both layers together, so there is no split between whoever owns the PBX and whoever owns the network.
The work follows a fixed method: mapping before any change, maintenance windows the organization defines, a way back at every stage, acceptance testing and full documentation of what is handed over. That is how projects finish on the date that was set rather than drifting.
The main systems we work with are Asterisk and FreePBX, which can run as a virtual server on the existing estate — under the same backup and the same monitoring as everything else. These are the platforms we work with most, not a closed list. If something else runs in your estate, we will design, build and maintain that too.
We work with organizations over years rather than over a single project — Ariston Group for around six years running the entire estate, Combe for more than fifteen, CooperVision and Galmarine for about five each.
The path
Five segments in the order a call crosses them. Pick a symptom and see where it is actually produced.
What are you hearing?
The handset or the software the employee actually speaks into. This is where speech becomes traffic — and from here on it competes for the same resources as everything else on the network.
Fully in your control
The switches the extensions sit on. Whether voice traffic is separated from ordinary traffic and given priority is decided here, not at the PBX.
Fully in your control
Asterisk or FreePBX — the extensions, the call routing and how the system behaves. It can run on a dedicated server or as a virtual server on the existing environment.
Fully in your control
The point where the call leaves the organization. Capacity here is shared with everything else the organization does online, so it gets measured under real load rather than assumed.
Partly in your control
The segment you do not configure. What you do with it is choose it, define what happens when it fails, and be able to tell that it is the one that failed.
Outside your control
Selecting one marks the segments responsible and shows what gets done there.
Echo, or choppy and broken audio
Voice is queued behind everything else. The moment the switch or the link is busy, the call’s packets wait like any other packet — and the ear hears that wait immediately.
Separating voice traffic and prioritising it at the access layer, and measuring the real load on the outbound link at the same time. That is work in the network, not in the PBX.
The networking and switching layerOne-way audio — one side cannot be heard
The audio comes back by a different route than it went out, and something in between does not know the two belong to the same call. It sounds like a PBX fault, but it is produced between the PBX and the perimeter.
Designing the PBX, the firewall and the way out as one path — and acceptance testing that runs the whole path rather than an internal call.
Security controls at the perimeterAt peak, calls drop or will not connect
The outbound link has hit its ceiling. Everything worked right up to that point, which makes it easy to blame the system that was replaced recently rather than the link nobody ever measured.
Measuring the existing links and the load on them before the design rather than after — and only then deciding whether the answer is prioritisation, capacity, or both.
A site loses connectivity and is left with no telephony
Nobody defined in advance what was supposed to happen. In most cases this is not a component failing — it is a decision that was never taken at design time.
Defining how the system behaves when connectivity fails, per site, as part of the specification. Across multiple sites that follows from how the branches are connected in the first place.
Site-to-site connectivityEvery new employee is another licence
This is not a fault, it is a model. A PBX priced per extension turns every hire into a line item and every reorganisation into a conversation with a supplier.
An open platform running on your own infrastructure: no per-extension licensing, visible configuration, and the system falls under the same backup and monitoring as the rest of the servers.
The virtual environment it runs onOf the five — three never touch the PBX at all, one is the PBX together with the perimeter, and the only one that is the PBX on its own is a question of ownership rather than a fault.
The platforms
FreePBX is not a competitor to Asterisk but a management layer over it. The real question is who operates the system day to day, and how far the required behaviour departs from the standard. Each has its own page.
Proof
Combe
Network infrastructure designed and built from the ground up at plants added to the group — the layer voice systems depend on.
Ariston Group
Management of the entire IT estate across ten branches connected to the central site over redundant links under a single policy.
The projects shown here are based on work delivered by the ILS team in customer environments.
FAQ
We build and maintain enterprise telephony systems on Asterisk and FreePBX — covering system design, deployment, integration with the network estate and ongoing maintenance. Each platform has its own page with the scope and the process.
FreePBX is a management layer running on top of Asterisk, so the engine is the same either way. The practical difference is who operates the system: FreePBX suits an in-house IT team making routine changes through a screen, and Asterisk directly suits behaviour that does not fit a standard screen. For some clients the answer is a combination, and that is decided during specification.
The practical reason is ownership and control: the system runs on your infrastructure, its configuration is visible, and there is no per-extension licensing that prices every new employee. It suits organizations already running serious infrastructure who want telephony to be part of it rather than a separate island.
Because that is where most of the symptoms live. Voice traffic is far more sensitive to delay and packet loss than ordinary traffic, so traffic separation, priority and the outbound links are part of the design rather than an appendix to it. The only thing worse than the wrong PBX is the right PBX on a network nobody touched.
Yes. In many cases the PBX runs as a virtual server on the same environment we already manage for you, which saves dedicated hardware and brings the system under the same backup and monitoring as the rest of the estate.
Ongoing maintenance is part of the service. For clients whose whole estate we manage, telephony is another layer under the same agreement — so a fault is investigated across the network, the servers and the PBX together, rather than across three vendors.
For most organizations today, a virtual PBX: software running on a server rather than dedicated hardware. It is cheaper to change, fits into the existing virtualization estate and is backed up like any other server. A physical PBX still fits where there are specific analogue connection requirements or a connectivity constraint at the site.
Usually not. Of the five most common enterprise telephony faults, three never touch the PBX at all — they sit in the network, in the carrier connection, or in QoS configuration. That is why we design the voice layer and the network layer together; working on the PBX alone leaves the cause in place.
Next step
A short technical call with the team: what runs today, how many extensions and sites, and what it takes to move without surprises — no commitment.
Thanks for contacting ILS Networks. We will come back to you shortly. If it is urgent, you can also call us directly.
+972-54-454-6020