Two products described in almost the same words can require completely different wiring. A cellular trunk gateway presents itself to a private branch exchange as a SIP peer; a bridge device sits between a mobile network and legacy equipment that has never spoken IP. Buying the wrong one is discovered at the rack, not in the specification.
This guide sets out how to tell the two apart, what the wiring consequences are, when a small desktop device is genuinely sufficient, and how to compare a cellular path against a SIP trunk on the terms that matter to the operation rather than to the datasheet.
What is the difference between a trunk gateway and a bridge device?
One presents a SIP peer; the other converts.
A trunk gateway terminates cellular calls and offers them to an IP platform as one or more SIP trunks, while a bridge device connects cellular voice to an interface the existing equipment already has.
The distinction is easiest to see from the platform side. If your private branch exchange can register a SIP trunk, you need a trunk gateway. If it cannot — because the equipment predates IP, or because the only available ports are analogue — you need a device that presents analogue or legacy interfaces rather than a SIP peer.
Confusing the two produces two predictable failures. A trunk gateway connected to equipment that expects analogue ports produces nothing at all, because there is no interface to connect to. A bridge device connected to an IP platform wastes the gateway capability you paid for, and usually leaves the platform unable to see call state. Establishing which interface your platform accepts is therefore the first decision, and it costs nothing to answer.
The signalling that a trunk gateway presents is defined by RFC 3261, and the call flows a platform expects to see follow the examples in RFC 3665, which is a useful reference when you need to confirm what the platform will accept before ordering hardware.
How do FXS, FXO and SIP interfaces differ in practice?
They differ in who supplies dial tone and who dials.
The choice determines which device behaves as the line and which behaves as the telephone.
A subscriber-line interface behaves like the telephone network: it supplies dial tone and accepts a call from the connected equipment. A office-line interface behaves like a telephone: it seizes a line and dials. A SIP interface behaves like neither, because the call is a signalling exchange rather than an electrical one.
In practice, the question to answer is which side of the connection initiates. Where the private branch exchange has spare trunk ports and expects the network side to be supplied, you are looking for a device that emulates the network. Where it has spare extension ports and expects to be treated as a line, the reverse applies. Where it speaks SIP, neither analogue interface is involved.
| What the PBX offers | Interface required | Practical consequence |
|---|---|---|
| SIP trunk configuration | SIP peer | Simplest integration, full call state visible to the platform |
| Spare trunk port expecting network | Subscriber-line emulation | Device supplies dial tone; platform sees the calls as inbound line traffic |
| Spare extension port expecting a line | Office-line connection | Device seizes the line and dials; call state is less visible |
| No spare ports | SIP plus platform replacement | Replacing the platform is often cheaper than adding interfaces |
Where the equipment is old enough that no ports remain, the arithmetic usually favours replacing it rather than adding conversion hardware. A small SIP gateway plus a modern platform frequently costs less than the interfaces required to keep legacy equipment in service, and it removes the analogue failure modes entirely.
When is a desktop device sufficient?
When the need is a few lines, not a call centre.
A single-channel device is often dismissed as too small, and then purchased anyway once the actual requirement is stated.
The GOIP1 at $100.00 provides one channel and one SIM slot. That is sufficient for a backup path, a single outbound line for a small office, or a test position for validating an integration before committing to a rack deployment. What it cannot do is carry concurrent calls, and any requirement expressed as concurrent is a requirement for more channels by definition.
The step up to the GOIP8 at $378.00 and the GOIP16 at $620.00 follows the same logic as any voice deployment: count the concurrent calls you must support at peak, and add headroom for the calls that arrive while others are in teardown. A small office with two conversation paths rarely needs more than four channels; a call centre needs one channel per agent who may be on a call simultaneously.
How does a cellular path compare with a SIP trunk on cost?
It wins on number authenticity, loses on capacity.
A SIP trunk delivers capacity cheaply; a cellular path delivers a mobile identity that a trunk cannot provide.
The comparison is therefore not purely financial. Where the requirement is that the called party sees a mobile number, or that the call appears to originate from the destination market, a SIP trunk cannot satisfy it at any price. Where the requirement is volume at low cost per minute, a SIP trunk is normally cheaper and simpler to scale.
The cost model for a cellular path has four lines: the gateway capital, the SIM estate, the site environment, and the operational effort. The last is the one that changes decisions, because a cellular deployment has physical dependencies — coverage, registration and SIM handling — that a trunk does not. Where the deployment already operates SIMs for messaging, those dependencies exist anyway and the marginal cost of adding voice is small.
For deployments that run both, keeping voice and messaging inside one product family reduces the operational delta. The published SK VOIP Gateway range runs from the 4-port model at $260.00 to the 32-port eSIM model at $3,100.00, and the GoIP series covers the entry tiers from $100.00 upward.
How do you verify the wiring before go-live?
Place one call each way and check the platform log.
Wiring faults are electrical and produce no log entry, so the first test is whether the call reaches the platform at all.
The sequence is short and worth following in order. Confirm the physical connection on the correct interface, with the correct cable for the interface type. Place an outbound call and confirm it appears in the platform log with the expected number. Place an inbound call and confirm it reaches an extension. Then confirm audio in both directions, which is a separate check from signalling and the one most often skipped. Finally, run the same three steps under load, because a marginal connection that works on one call can fail when a second is added.
Where an interface is analogue, keep a note of which physical port maps to which logical trunk. Legacy equipment frequently has no way to report that mapping, and a later fault cannot be diagnosed without it.
What causes one-way audio over a cellular trunk?
Usually a media path problem, not signalling.
Signalling completes and the call connects, so the fault is in the path the audio takes rather than in the path the call took to set up.
Four causes cover most cases. A network address translation device between the gateway and the platform may rewrite the media address so that one side sends audio to an unreachable address. A codec may be negotiated that one side cannot process, producing an apparently connected call with no audio. A firewall may permit signalling and block the media range. Or the cellular side may have poor uplink quality in one direction, which is a coverage problem rather than a configuration one.
The diagnosis order follows the likelihood. Read the negotiated codec from the platform log first, because that is the cheapest check. Then confirm the media address both sides are using, which resolves the address translation and firewall cases together. Only then investigate coverage, because it is the most expensive to change. Both Asterisk and FreeSWITCH document how to inspect negotiated media parameters, and reading the platform you run shortens the diagnosis considerably.
Where a specification has to reference the numbering or interconnection conventions a carrier expects, the publications of the ITU Telecommunication Standardization Sector provide a neutral reference point, and the numbering framework itself is defined under ITU Recommendation E.164.
Conclusion
Trunk gateway or bridge device is decided by the interface your platform accepts, not by the specification sheet, and answering that question first prevents the two predictable failures: a device with no port to connect to, and a bridge wasting gateway capability. Where the platform speaks SIP, the integration is standardised and the call state remains visible; where only analogue ports remain, the mapping between physical port and logical trunk has to be recorded because the equipment cannot report it.
Capacity follows the same logic as any voice deployment: count the concurrent calls required at peak and add headroom, which puts a small office at the low end of the GoIP series from $100.00 and a call centre in the SK VOIP Gateway range from $260.00 upward. Cost comparisons between a cellular path and a SIP trunk should separate the identity requirement from the volume requirement, because only the second is a price question.
Confirm which interface your platform accepts before ordering. Send your private branch exchange model, available ports and concurrent call requirement to service@telarvo.com, or review the published models on the VoIP gateway solution pages.
FAQ
Can a trunk gateway connect to old analogue equipment?
Not directly, because a trunk gateway presents itself as a SIP peer rather than as an analogue interface. Equipment that predates IP needs a device that presents the interface it expects, or a platform replacement. Where no spare ports remain, replacing the platform is frequently cheaper than adding conversion hardware, and it removes the analogue failure modes at the same time.
How many channels does a small office need?
Count the number of people who may be on a call at the same time and add one for calls in teardown. A small office with two simultaneous conversation paths rarely needs more than four channels. Requirements expressed as total call volume rather than concurrent calls lead to over-purchasing, because a hundred short calls handled two at a time need two channels, not a hundred.
Is a cellular trunk more expensive than a SIP trunk?
For volume at low cost per minute, SIP trunking is usually cheaper and easier to scale. A cellular path earns its cost when the requirement includes a mobile identity, a destination-market number or independence from an IP path. Where the deployment already operates SIMs for messaging, the marginal cost of adding voice channels to the same estate is small.
Why does the call connect but carry no audio?
Because signalling and media take different paths and only one of them succeeded. Check the negotiated codec first, then confirm the media address both sides are using, which resolves address translation and firewall causes together. If both are correct, investigate cellular coverage at the installed position, since one-directional radio quality produces the same symptom.