3CX is the platform where the device list decides the project. Where a gateway appears on the supported list, integration is largely a matter of following a template; where it does not, the same hardware becomes a generic SIP trunk configuration and the effort moves from following instructions to establishing behaviour.
This guide covers that fork: what the platform requires of a gateway, how to establish whether a model is supported, which registration model it expects, how number format is handled, and what to confirm when the model you want is not on the list.
What does the platform require of a gateway?
A supported model, or a generic SIP trunk.
The requirement is about integration surface rather than about capability, and the same device can satisfy one path and not the other.
Two integration paths exist. A supported device is one the platform documents, for which a configuration template exists and the expected parameters are known. A generic trunk is a standards-based SIP endpoint the platform will accept, but whose behaviour it does not describe. Both carry calls; they differ in how much of the behaviour is documented rather than discovered.
Three properties determine which path applies. Whether the model appears on the platform’s supported list. Whether the gateway can be configured to match the registration and number conventions the platform expects. And whether the platform’s codec expectations can be met without transcoding. The first is a lookup, and it should be done before the hardware is ordered rather than after.
How do you check whether a model is supported?
From the platform’s supported device list.
The list is maintained by the platform rather than by the gateway vendor, and it changes with platform releases.
Three steps make the check reliable. Consult the platform’s current supported list rather than a vendor claim, because the two can differ after a platform release. Confirm the specific model rather than the product family, since support is frequently listed by model. And record the platform version the check was made against, because support can be added or withdrawn between releases.
Where the model is listed, follow the platform’s template rather than a gateway-side guide. Templates encode the parameters the platform expects, and deviating from them reintroduces the registration problems the template exists to prevent. Where the model is not listed, the next sections describe the generic path.
Which registration model does the platform expect?
Usually the gateway registering to the platform.
Direction is the first decision, and it determines whether the configuration on one side is even relevant.
Most platform integrations expect the gateway to initiate and maintain the registration, presenting credentials that the platform validates. Where the platform is configured for a gateway that registers, a device configured to be registered to will produce silence rather than an error, because no request is being sent in the expected direction. That silent failure is more time-consuming to diagnose than an authentication failure, which at least appears in the log.
Establish the direction from the platform’s documentation before configuring anything, and confirm it by looking for a completed registration in the platform log rather than in the device console. The device’s own view of whether it is registered describes its intention rather than the negotiated state.
How is number format handled?
One format on the trunk, translated in one place.
The platform expects a consistent presentation, and inconsistency produces calls that connect and reach the wrong destination.
Two formats are conventional: a national format without country code, and an international format with it. Which the platform expects depends on its configuration, and the practical requirement is that the gateway presents one format consistently rather than a mixture determined by the source of the call.
The rule that prevents most faults is single-point translation. Where the gateway converts and the platform converts again, the result is a number neither side intended, and the fault appears intermittently because it depends on which conversion ran last. The international format itself is defined by the ITU Recommendation E.164 numbering plan, which is the reference to cite when the presentation has to be stated in a specification.
What changes when the model is not on the list?
The effort moves from template to discovery.
The hardware is not disqualified, but the integration becomes a project with unknowns.
Three consequences follow. Registration behaviour has to be established empirically rather than read from a template, which means testing both directions. Number format has to be verified by reading the log rather than by assuming the documented convention. And codec negotiation has to be confirmed, because a codec mismatch produces calls that connect with no intelligible audio and is frequently misdiagnosed as a gateway fault.
The generic path is entirely workable, and it is more reliable when the three unknowns are resolved before the deployment carries live traffic. The signalling it relies on is defined by RFC 3261, with call flows illustrated in RFC 3665, and reading those definitions is faster than experimenting with settings.
Where the underlying platform is open source, the documentation for Asterisk or FreeSWITCH describes how registration and failover are handled, which is useful context even when the platform is not the one being deployed.
How should codecs be chosen?
Choose one both sides negotiate natively.
Transcoding consumes resources on both sides and introduces a failure mode that is difficult to distinguish from a network problem.
The safe starting point is a widely supported narrowband codec that both the gateway and the platform list as supported, with transcoding avoided. Where the cellular side imposes a codec the platform does not support, transcoding becomes necessary, and its cost should be measured rather than assumed: on a lightly loaded device the effect is invisible, and on one running near its channel capacity it can be the difference between meeting a peak and dropping calls during it.
Digit signalling belongs in the same decision. Carrying keypad digits within the audio stream survives simple paths and degrades when the codec compresses aggressively; out-of-band signalling is more robust where both sides support it. The practical test is to dial a menu-driven service and press keys during the prompt, because a failure there is a signalling problem rather than a gateway fault.
What should be recorded at handover?
Model, template, format, codec, test results.
The record is what makes a later behaviour change comparable rather than mysterious.
| Item | What to record |
|---|---|
| Support status | Whether the model was on the supported list, and the platform version checked |
| Registration | Direction, credentials, and the transport in use |
| Number format | The presentation used, and the single point at which translation happens |
| Codec | The negotiated codec, and whether transcoding occurs |
| Versions | Platform version and gateway firmware version at acceptance |
| Test results | Both call directions, audio, digit signalling, and the failure path |
Item one is worth recording explicitly because it determines how much of the rest was documented and how much was established during integration. A later engineer inheriting a generic-path deployment needs to know that the behaviour was discovered rather than specified.
Where the integration must satisfy an equipment framework, the ETSI standards catalogue covers the network and equipment side of the same requirement.
Where the model is not listed, the integration should be documented as a discovery rather than presented as a supported configuration. Recording what was established — the registration direction that worked, the number format the platform accepted, the codec that negotiated — is what allows a future platform update to be assessed against a known starting point rather than treated as an unexplained change in behaviour.
A second consideration is failover. Where the deployment keeps an alternative path, the platform’s behaviour when the gateway becomes unavailable should be tested rather than assumed, because a trunk that fails silently is indistinguishable from one that is working until someone tries to place a call. Testing the failure path at commissioning converts an assumption into a documented behaviour, and it costs one configuration change.
Where several gateways are integrated, apply the same discovery record to each rather than assuming the first result carries across models, because a platform update can affect one configuration and not another depending on how each was registered.
Conclusion
A 3CX integration is decided by the supported device list, which is a lookup rather than a judgement. Where the model is listed, following the platform’s template is faster and more reliable than configuring the gateway from a vendor guide. Where it is not, the deployment becomes a generic SIP trunk integration, and the effort moves to establishing registration direction, number format and codec behaviour empirically before live traffic arrives.
Recording the support status alongside the configuration is what makes the difference visible to whoever inherits the deployment. The published SK VOIP Gateway range from the 4-port model at $260.00 upward provides the endpoint model across the tiers, and the GOIP16 at $620.00 covers deployments where the field unit is separate from the platform location.
Check the supported device list before ordering. Send your platform version, intended trunk type and number convention to service@telarvo.com, or review the published models on the VoIP gateway solution pages.
FAQ
Is a gateway useless if it is not on the supported list?
No, but the integration changes character. A listed model comes with a template and documented parameters; an unlisted one is configured as a generic SIP trunk, which is entirely workable provided registration direction, number format and codec behaviour are established before live traffic. The difference is in how much of the behaviour is documented rather than discovered.
Should the gateway register to the platform or the other way round?
Follow the platform’s documentation, which for most integrations expects the gateway to register with credentials. A device configured for the opposite direction produces silence rather than an error, which is harder to diagnose than an authentication failure. Confirm by looking for a completed registration in the platform log rather than in the device console.
Why does the call connect but carry no audio?
Usually a codec negotiation or media path problem rather than a signalling one. Read the negotiated codec from the platform log first, then confirm the media address both sides use. Digit signalling deserves a separate test: dial a menu-driven service and press keys during the prompt, because a failure there indicates the signalling method rather than the gateway.
What is the difference between a SIP trunk and a gateway in this integration?
The trunk is the logical path the platform routes calls over; the gateway is the device that terminates calls on the cellular network and presents them to the platform. In this configuration the gateway acts as the trunk endpoint. The distinction matters when specifying, because the two are purchased from different sources and configured in different places.