Operation

Kamailio: the switch's doorman

Kamailio is the doorman. Every incoming call reaches it first: it looks at who is calling, checks whether they are allowed, decides whether to let the call through and where to send it. It does not carry the audio — another part does that — but no call exists unless Kamailio let it in.

Settings → Kamailio shows what the doorman is doing right now and lets you adjust what can be adjusted without dropping calls. It is split into tabs so each thing is where you would look for it.

Know this before changing anything: some changes apply instantly and disturb nobody, and others need the doorman restarted — and a restart drops every call in progress. The screen always tells you which is which. Anything under the "Needs a restart" tab cannot be changed live.

Status

The snapshot. Which version is running, how long it has been up, which addresses it answers on, how much memory it is using, and how many calls it has right now, split between answered and ringing.

You also see the worker processes. They are the doorman's staff: each one handles a call at a time. They are assigned per entrance and are not shared between entrances — if the staff on one door are all busy, the ones on the other do not help. That is why they are shown separately and not as a single total, which would hide the problem.

Modules

Kamailio is assembled from parts, each doing one job. Here are the ones this switch has installed, with what each is for: which handles gateway registrations, which the anti-fraud control, which talks to the database.

Read-only. Adding or removing a part needs a restart.

Memory

The doorman keeps quick notes in memory: how many calls per second each customer is making, which IPs are in the sin bin, the limits the operator set. Each notebook shows how many notes it holds.

Empty does not always mean the same thing. Some notebooks clear themselves every few seconds — empty is normal, especially with no traffic. Others are filled from the database: those being empty is a symptom, it means something did not load. The screen tells you which is which.

Limits

This is where the caps are set, and they apply instantly without dropping any call. Three different things, worth not confusing:

  • Simultaneous calls — how many at once.
  • Calls per second — how fast they may arrive.
  • Daily spend — how much an account may spend in a day.
The licence is the ceiling and cannot be crossed. If your server is licensed for 200 simultaneous calls, the screen will not accept a number that would allow more. It tells you the maximum and why. Exceeding the licence breaches it, and the panel refuses the number at the moment you save it.

One detail the screen explains, which surprises people. The licence counts answered calls, but the switch's caps count calls in progress, which includes everything still ringing. Far more ring than answer. On this traffic there are about three calls in progress per answered one, so a 200-call licence works out to a cap of about 600 in progress. That number comes from measuring real traffic, not from a formula.

Reload

When you change something on another screen — a customer, a rate, a connection point — the doorman does not find out by itself: you have to ask it to read again. That is a reload, and it drops no calls: it just says "look again".

Each button says what it re-reads and, more importantly, what it does not cover. Reloading the wrong thing, seeing no change and concluding the panel is broken is a common trap.

About routes: the routing rules only contain gateways that are registered at that moment. Reloading while a gateway is down loading nothing for it is correct, not a fault. It comes back on its own when the gateway registers.

Needs a restart

The list of what cannot be changed live: how many worker processes, which addresses it listens on, which parts are loaded, and the memory reserved at start-up.

It is listed on purpose, so it is never a surprise. Anything here needs the doorman restarted, and that drops every call in progress. It is done in a maintenance window, not on the fly.

Admission

The most useful tab when something does not add up. It answers a question that looks obvious and is not: what can actually reject a call?

The switch has an anti-fraud score with several signals. Each adds points, and the call is rejected when the score reaches the threshold. The catch is that a configured limit is not always enough to reject: it may add fewer points than the threshold and, on its own, stop nothing.

A control can be set and visible and still not be the one that refuses: it may add fewer points than the threshold. The screen spells out which combination of signals is actually needed for a call to be rejected.

You will also see signals marked disarmed. Usually because the customer's cap is zero, which the switch reads as "no limit" — and switches that signal off along the way. The screen tells you which one is off and why.

Who gets in, and who is blocked

The list of who may send us traffic without authenticating, and who is in the sin bin right now. A customer who gets their password wrong a few times bans themselves; you can lift it from here rather than waiting.

The allowlist is not edited here. It is built from the connection points: to authorise an IP, add it to the connection point and the list follows. It is edited in one place on purpose: two sources for the same list is how hard-to-diagnose inconsistencies appear.
© 2026 NEXIA Networks · This wiki grows with every install: if something was missing, tell us and we add it.
On this page