The integration that takes longest is rarely the one with the most complex configuration. It is the one where nobody wrote down the number format the gateway presents, so routes are written against an assumption and every call that happens to match connects while the rest disappear.
This guide is the PBX-side checklist for a SIP cellular gateway: what the platform needs before it will accept the device, how the presented number should be formatted, how registration is confirmed from the platform’s own log, what the media path requires, and what has to be recorded before the deployment is handed to whoever operates it next.
What does the PBX need before it accepts a cellular gateway?
An endpoint definition, a registration model and a route.
Three configuration elements have to exist on the platform side, and each is verifiable independently.
The endpoint definition tells the platform that a device will present calls. Depending on the platform, that may be a peer described by address, an endpoint described by credentials, or a trunk of a specific type. The registration model determines which side initiates: the gateway registering to the platform, or the platform registering to the gateway. The route tells the platform where calls from that endpoint should go, and where calls destined for it should be sent.
Establishing the three in that order prevents the most common integration loop, in which routes are configured before it is known what the gateway will present, and the resulting failures are attributed to the device. The registration model in particular should be copied from the platform’s own documentation rather than chosen on the gateway, because the platform’s templates encode what it expects.
Where the platform is open source, the documentation for Asterisk or FreeSWITCH describes the registration and failover behaviour you are configuring against, and reading the one you run is faster than experimenting on the device. The underlying signalling is defined by RFC 3261, with call flows illustrated in RFC 3665.
Which number format should the gateway present?
One format, decided once, applied on one side only.
The presented number has to match the routes, and translation should happen in exactly one place.
Two conventional formats exist. A national format omits the country code and may include a trunk prefix; an international format includes the country code and no prefix. Which is correct depends on the platform’s convention, and the practical requirement is that the gateway presents the format the routes expect rather than the format that happens to be convenient.
The rule that prevents most failures is single-point translation. Where the gateway converts from national to international and the platform converts back, the result is a number neither side intended, and the fault appears intermittently because it depends on which conversion ran last. Choose one side to translate and configure the other to pass the value through unchanged. The international format itself is defined by the ITU Recommendation E.164 numbering plan, which is the reference to cite when the presented format has to be stated in a specification.
The verification step is short and worth doing before any route is written: place one inbound call and read the exact value from the platform log. That value, rather than the assumption, is what the route should match.
How do you confirm registration from the PBX side?
Look for a completed registration, not for an attempt.
Registration logs distinguish between authentication failures and silence, and the distinction points at different causes.
Three outcomes are common. A session that never appears in the log suggests the request is not reaching the platform, which points at the network path or the transport. Repeated authentication attempts with no success suggest a credential or direction mismatch. A successful registration followed by repeated re-registration suggests a keep-alive or expiry mismatch between the two sides.
Confirming registration from the platform log rather than the device console is deliberate: the platform is the party that decides whether the session is usable, and a device that reports itself registered is describing its own view rather than the negotiated state.
What should the media path look like?
Signalling and media take different paths.
A call that connects with no audio is a media path problem, and it is diagnosed by reading the negotiated parameters rather than by changing gateway settings.
Three conditions have to hold. The negotiated codec must be one both sides can process without transcoding where possible. The media address each side uses must be reachable from the other, which is where a translation device between them causes one-way audio. And the firewall must permit the media range, not only the signalling port.
The diagnosis order follows the likelihood. Read the negotiated codec from the platform log first, because it is the cheapest check. Then confirm the media addresses both sides are using, which resolves the translation and firewall causes together. Only then investigate cellular conditions at the installed position, because one-directional radio quality produces the same symptom and is the most expensive to change.
How do inbound calls reach extensions?
By matching the presented number to a destination.
Inbound routing fails silently when a number matches nothing, so a default destination is a requirement rather than a refinement.
The sequence is: confirm what the gateway presents, write routes against that exact value, and define what happens when nothing matches. Most platforms log the inbound invitation with the presented number, and reading it before writing the route converts a guessing exercise into a configuration task.
Two design decisions belong here. Whether one number serves many destinations or each number maps to one, which trades number inventory against routing complexity. And what the default destination is, because a call that matches nothing and has nowhere to go produces no record and no callback.
Where the deployment serves several business lines, keep the mapping documented per line rather than in one table. A mapping that is correct but unreadable is not usable during an incident, and incidents are when it is read.
What breaks after a firmware update?
Behaviour that was configured rather than documented.
An update can change defaults, and defaults that were relied on silently are the ones that break.
Three areas are worth re-testing after any firmware change: registration behaviour, because keep-alive and expiry defaults may shift; codec negotiation, because the offered set may change; and number presentation, because a formatting default may be reset. None of those is a defect in the update, and all three produce symptoms that look like a platform problem.
The mitigation is procedural rather than technical. Record the firmware version alongside the acceptance results, apply the update to one device before the estate, and repeat the registration and call tests on that device before rolling out. Where a security fix is the reason for the update, the test run is what turns it from a risk into a maintenance task.
| Item | What to record |
|---|---|
| Registration model | Which side registers, and with which credentials |
| Transport | Protocol and port used between gateway and platform |
| Number format | Presented format, and the single point at which translation occurs |
| Codec | Negotiated codec, and whether transcoding occurs |
| Routing | Route table with its default destination |
| Versions | Firmware version and platform version at acceptance |
| Test results | Call tests in both directions, and the failure-path results |
A handover point worth recording explicitly is the behaviour of the deployment when the platform itself is unavailable. The gateway may reject calls or hold them, and the two produce very different experiences for a caller. Where the platform is upgraded during a working day, that behaviour determines whether callers experience a recorded message or silence, and it is a configuration decision rather than a fault.
Where the deployment is expected to grow, record the channel count that remains available before the next device is required. A gateway integration that consumes most of the platform’s trunk capacity leaves the next requirement with nowhere to land, and the second integration is more expensive than the first because it has to work around a constraint rather than within one.
Where the deployment also handles messaging, the SK-SMS Gateway range provides a dedicated messaging device so that voice and messaging do not contend for the same channels.
Conclusion
A SIP cellular gateway integration comes down to three decisions made explicitly: the registration model, which the platform should drive; the presented number format, with translation in exactly one place; and the default destination for calls that match no route. Confirming registration from the platform log rather than the device console, and reading the negotiated codec before investigating audio problems, resolve most of the remainder.
Recording the configuration and the acceptance results together is what makes a later behaviour change interpretable. A firmware update that shifts a default is a maintenance task when there is a baseline to compare against and an incident when there is not. The published SK VOIP Gateway range from the 4-port model at $260.00 upward covers the integrations most teams start with, and the same registration model applies across the tiers.
Confirm the registration model and number format before configuring routes. Send your platform, trunk type and number convention to service@telarvo.com, or review the published models on the VoIP gateway solution pages.
FAQ
Should the gateway register to the PBX or the reverse?
Follow the platform’s own documentation, because it encodes the model the platform expects. Where the platform documents a gateway endpoint of a particular type, configuring the device to the same model removes most of the ambiguity. A mismatch in either direction produces repeated authentication attempts with no successful session, which is the most time-consuming integration fault to diagnose.
Which number format should the gateway present?
The one the platform’s routes expect, whether that is national or international, and it should be translated in exactly one place. Where both sides translate, the result is a number neither intended and the fault appears intermittently. Confirm the presented value by reading it from the platform log on a real inbound call rather than from the specification.
Why does the call connect but carry no audio?
Because signalling and media take different paths and only one succeeded. Check the negotiated codec first, then confirm the media address both sides use, 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.
What should be re-tested after a firmware update?
Registration behaviour, codec negotiation and number presentation, because each can be affected by a changed default rather than by a defect. Apply the update to one device, repeat the acceptance tests on it, and record the new firmware version alongside the results. A baseline recorded at acceptance is what turns an update into a maintenance task rather than an incident.