Outbound traffic is measured in attempts and outcomes. Inbound traffic is measured in whether the right person answered, and a gateway that handles outbound perfectly can still lose a call because the number that arrived did not match any route.
This guide covers the inbound half of a gateway deployment: how number mapping decides where a call lands, when one number should serve several lines, how to handle a busy or unanswered call so that it does not vanish, what causes inbound failure, and how to test the result with cases that matter rather than a single successful call.
How does a call find its way to the right extension?
By matching the presented number to a destination.
The gateway presents the incoming number, the platform matches it against a route, and the route names the destination.
The chain has four links: the carrier delivers the call to a specific SIM; the gateway associates that SIM with a presentation format; the platform matches the presented value against a route; and the route names an extension, ring group or announcement. A failure at any link produces a call that arrives and then goes nowhere, and the log entry usually identifies which link failed.
The most common mistake is to configure the route before confirming what the gateway presents. Numbers arrive in the format the carrier uses, which may include a country code, a trunk prefix or both. Writing a route against an assumed format produces intermittent behaviour, because calls that happen to match succeed and the rest disappear.
Read the inbound invitation from the platform log once, record the format, and write routes against that exact value. Where a market uses a national format that differs from the international one, the conversion should happen in one place — either the gateway or the platform, not both. The international format itself is defined by the ITU E.164 numbering plan, and following it consistently on the inbound path removes an entire class of matching problems.
Should one number serve many lines, or one line each?
One number per line is simpler; fewer conserve numbers.
The choice determines your number inventory, your routing logic and how much your support team has to explain.
One number per line maps a SIM to a destination and nothing more. The routing table is short, a fault localises to a single mapping, and a customer who saves the number reaches the same place every time. The cost is number consumption: a deployment with forty destinations needs forty numbers, and in markets where numbers are scarce or require registration, that constraint is real.
One number for many lines moves the routing decision into the platform, usually by prompting the caller for a selection or by matching a time-of-day rule. It conserves numbers and centralises routing logic, at the cost of an extra interaction for the caller and a routing table that is harder to reason about at three in the morning.
A third pattern is worth knowing because it suits gateway deployments well: a small group of numbers serving a larger group of destinations, with the mapping defined per group rather than globally. It keeps the routing table comprehensible while avoiding the number consumption of strict one-to-one mapping.
Whatever the pattern, the mapping should live in one place and be documented. Deployments that define some mappings in the gateway and some in the platform end up diagnosing the same fault twice.
How should busy and unanswered calls be handled?
Give every route a fallback that exists.
An unanswered call is a routing decision, and a route without a fallback discards it.
Three options cover most requirements. A ring group presents the call to several destinations and connects whichever answers first, which suits teams where availability matters more than identity. A queue holds callers in order and is appropriate where the call must not be lost and a short wait is acceptable. A fallback destination — an announcement, a voicemail box, or another number — is the minimum, and it is the option most often missing.
The design question is what happens at the moment of failure rather than in the normal case. Busy, no answer, and network failure are three different conditions, and platforms can usually treat them separately. Deciding that a busy destination overflows to a colleague while a network failure overflows to a fallback number is a small piece of configuration that removes a large category of silent call loss.
Where the gateway itself cannot reach the platform, the behaviour is different again, because the call has nowhere to be routed. Confirm what the gateway does in that state: whether it rejects the call or holds it. A gateway that holds a call while the platform is unavailable is preferable where the caller can wait, and a gateway that rejects promptly is preferable where the caller should try another route instead of waiting in silence.
What causes inbound calls to fail?
Four causes account for nearly all inbound failure.
Each has a distinct symptom, which makes the order of checks matter.
- Number format mismatch. The presented value does not match the route. The symptom is that the platform logs the call as unmatched, or a default destination answers instead of the intended one.
- SIM registration loss. The SIM that receives the call is no longer registered, so the call never reaches the gateway. The symptom is silence at the platform, with nothing in the log at all.
- Channel saturation. All channels are occupied by outbound traffic, so the inbound call is rejected by the network or by the device. The symptom is that inbound calls fail during outbound peaks and succeed otherwise.
- Media path failure. Signalling completes but audio does not flow in one or both directions. The symptom is a connected call with no audio, which teams often misattribute to the carrier.
The order of checks follows from the symptom. Nothing in the platform log points at registration, so verify SIM state first. A log entry with an unmatched number points at routing. Failures that correlate with outbound volume point at channel saturation, and a connected call without audio points at the media path.
How does a gateway work alongside SIP trunking?
Treat the gateway as one trunk among several.
Most deployments that need resilience already run a SIP trunk, and combining the two is a routing decision rather than a technical one.
The gateway brings something a SIP trunk cannot: a local mobile number that rings on a handset without an application. The SIP trunk brings capacity and reach that a SIM estate cannot match economically. Routing inbound calls across both means deciding which numbers arrive on which path and what happens when one path fails, and that decision should be visible in the routing table rather than implicit in the order rules happen to be evaluated.
Two configurations work well. Where the gateway is primary, the SIP trunk carries overflow and acts as a fallback for numbers the gateway does not serve. Where the SIP trunk is primary, the gateway carries specific numbers that must appear as mobile numbers. In both cases, the test is whether a call placed during a failure of the primary path still reaches a destination.
The signalling behaviour that makes this work is standardised in RFC 3261, with call flows described in RFC 3665, and platforms that implement it fully will fail over between trunks according to configured rules. Where the platform you run is open source, the documentation for Asterisk or FreeSWITCH describes how failover between trunks is triggered, which is worth reading before designing the routing table.
What should an inbound acceptance test cover?
Test the failure cases, not the working case.
A single successful inbound call proves that one route works on one number at one moment.
Five cases cover the ground. Call each mapped number and confirm the intended destination answers. Call a number whose destination is deliberately busy and confirm the overflow behaves as configured. Remove a SIM from service and confirm the platform logs the failure rather than silence. Place an inbound call while outbound traffic is at peak and confirm the call still connects. And confirm the call detail records attribute each inbound call to the SIM that received it, because that attribution is what makes a later investigation possible.
Keep the results. When a customer reports that a call was not answered, the difference between an attributable record and no record determines whether the conversation is about your routing or about their expectation.
Conclusion
Inbound routing is a matching problem wrapped in a capacity problem. Matching starts with reading the number the gateway actually presents rather than assuming a format, and it ends with a route table in which every entry names a destination and every failure names a fallback. Capacity enters because inbound calls and outbound traffic share the same cellular channels, so a deployment that saturates its ports with outbound work will fail inbound calls precisely when they matter.
The two habits that prevent most inbound incidents are attributing call records to the receiving SIM and testing the busy and unanswered cases rather than only the working one. Where inbound numbers are customer-facing, a smaller number of well-mapped numbers is easier to operate than a large routing table with several presentation formats in play, and the published SK VOIP Gateway range from the 4-port model at $260.00 upward lets the channel count follow the inbound commitment rather than the outbound volume.
Map inbound numbers before you size the channels. Send your inbound number count, expected call volume and failover requirement to service@telarvo.com, or review the published models on the VoIP gateway solution pages.
FAQ
How many inbound numbers can one gateway serve?
The limit is normally the number of SIM slots, not the number of ports, because each inbound number is associated with a SIM that receives the call. A gateway with 16 ports and 64 SIM slots can present up to 64 numbers while using 16 channels for concurrent calls. Confirm the mapping model you intend to use, since one number per destination consumes inventory faster than grouped mapping.
What happens to an inbound call when all channels are busy?
It depends on configuration and on the carrier. The network may reject the call, or the device may hold it until a channel frees. Decide which behaviour you want before go-live, because a rejected call at least produces a record while a held call produces silence. Where inbound latency matters, reserving channels for inbound traffic prevents outbound peaks from occupying them.
Why do inbound calls stop working when outbound volume rises?
Because both directions use the same cellular channels. When every channel is occupied by an outbound campaign, an inbound call has nothing available to land on. The remedies are to reserve SIM slots for inbound use, to cap outbound concurrency below the port maximum, or to add channels. The first two cost nothing and usually resolve the problem without more hardware.
Can inbound calls be recorded and attributed for disputes?
Attribution is straightforward where call detail records identify the channel and SIM that received the call, which the device log provides. Recording is a platform-side function and depends on your private branch exchange rather than the gateway. Where attribution matters, verify that inbound records appear with the receiving SIM identified before go-live rather than reconstructing them after a dispute.