A single chassis carrying both messaging and voice is an attractive proposition until the first campaign coincides with a call peak. Both workloads use the same cellular channels, and the chassis does not decide between them on your behalf; the decision has to be made in configuration, before the traffic arrives.
This guide covers the sizing arithmetic for a combined deployment: how to budget channels across two workloads, how to partition ports and SIM slots so the reservation is enforceable, what happens to messaging when calls spike, and how to establish the point at which the two workloads should be separated rather than scheduled.
Can one chassis really carry both workloads?
It can, if the channels are reserved rather than shared.
The hardware supports both; the question is whether the configuration guarantees each workload the capacity it needs at the moment it needs it.
Three properties make a combined deployment workable. The device must support per-port or per-group configuration, so that a reservation is a configuration object rather than a convention. The SIM estate must be large enough to give each workload its own numbers, so that per-number policy on one does not constrain the other. And the platform must be able to apply its own scheduling, because the device decides what to transmit rather than which workload deserves priority.
Where any of the three is missing, the combined deployment becomes a shared-resource argument resolved by load. That is acceptable when neither workload carries a commitment, and unacceptable the moment one does, because the workload without a commitment will always win the race for a channel.
How do you budget channels across two workloads?
Reserve for the committed workload first.
The arithmetic is a sequence rather than a single calculation, and the order matters.
Start with the workload that has a published commitment, which is usually messaging with a delivery window or voice with a concurrent-call target. Determine the channels that workload needs to meet its commitment independently of the other, and reserve them. Then allocate the remaining channels to the other workload, and confirm that the residue still satisfies its own requirement. Where it does not, the chassis is undersized for the combination and the decision is to buy more channels or to separate the workloads.
Two corrections apply. Channels in teardown or with a SIM re-registering are briefly unavailable, so a reservation that exactly matches the committed requirement has no margin. And both workloads peak at different times of day in most operations, which means the sum of the two peaks overstates the simultaneous requirement — unless the peaks overlap, which has to be established from traffic data rather than assumed.
Where the peaks do overlap, the budget is the sum. Where they do not, the budget can be the larger of the two plus a margin, provided the overlap is genuinely rare and the consequence of a delay is acceptable. Writing down which assumption applies is what makes the budget revisable.
How should ports and SIMs be partitioned?
Give each workload its own ports and its own numbers.
Partitioning both resources is what makes the reservation structural rather than statistical.
| Partition | What it reserves | When it applies |
|---|---|---|
| Port groups only | Channels, but numbers are shared | Where per-number policy is permissive and numbers are interchangeable |
| SIM groups only | Numbers, but channels are shared | Rarely useful, because channel contention is the binding problem |
| Port and SIM groups together | Both, per workload | Where either workload has a commitment |
| Separate devices | Everything | Where both workloads carry commitments or must be independently evidenced |
Partitioning both is the configuration most deployments settle on, because it makes the reservation visible in the management interface and attributable in the logs. A later operator who finds idle ports can see that they belong to a group rather than to the estate, which is the difference between a documented reservation and an apparent waste.
Where the deployment serves commercial messaging, the identity used for each workload should also be separate. A recipient who receives a promotional message and then stops receiving service messages will conclude that the first caused the second, and the same reasoning applies when a voice line shares an identity with a messaging stream.
What happens to messaging when calls spike?
With a reservation, nothing; without one, messages queue.
The failure mode is predictable and worth testing deliberately rather than discovering.
Where channels are shared, an inbound call surge occupies the radios that messaging would use, and messages wait for the duration. Where the messaging workload has a time-bounded purpose — a verification code, or an appointment reminder an hour before the appointment — a queued message is a failed message rather than a delayed one, and the failure stays invisible until a recipient complains.
The test that exposes this is straightforward: drive voice to the concurrent maximum the deployment will see, submit a messaging batch at the same time, and measure messaging latency against its commitment. With a reservation, the measurement should be unchanged from a quiet period. Without one, the difference is the cost of sharing.
A second effect is less obvious: a messaging burst can affect call setup time. Sending a batch occupies radios briefly but repeatedly, and at a messaging peak a call may take longer to set up. Where the voice workload has a setup-time target, that interaction belongs in the same test.
When must the workloads be separated?
When both carry commitments, or each needs evidence.
Separation is the answer more often than the arithmetic first suggests, because the second condition is common.
Three situations require separate hardware. Where both workloads have published commitments that the other could break. Where an investigation must be able to demonstrate that one workload did not affect the other, which is difficult when both share radios and a log. And where a growth path would make the reservation disproportionate, such as a messaging volume that will exceed the residue within a year.
Where separation is chosen, the two devices should stay within one product family so the operating model does not diverge. The published range covers both sides: the SK-SMS Gateway line for messaging from the 4-port model at $238.00 upward, and the SK VOIP Gateway line for voice from the 4-port model at $260.00 upward. Keeping both in one family means the same console conventions, log format and acceptance tests apply to each.
What should the acceptance test cover?
Each commitment, measured while the other peaks.
A test that runs the workloads in sequence proves nothing about a combined deployment.
- Reservation enforced. Confirm the reserved ports are not used by the other workload, under load.
- Messaging latency at a voice peak. Submit a batch while calls are at maximum and measure against the messaging commitment.
- Call setup at a messaging peak. Measure call setup time while a batch is transmitting, against the voice target.
- Attribution. Confirm the log distinguishes the workloads per port group, so a later investigation can separate them.
- Recovery. Restart the device with both workloads active and confirm each returns to service without intervention.
- Growth headroom. Confirm the residue after reservation still satisfies the second workload at its projected volume.
Items two and three are decisive, because they measure each commitment under the condition that threatens it. Item six is the one that prevents the deployment being revisited within a year, and it is the item most likely to change the architecture rather than the configuration.
The reservation should also be visible in reporting rather than only in configuration. Where the log attributes each message and each call to a port group, the effect of any future change can be measured against a baseline; where it attributes only to the device, a change in one workload’s behaviour is indistinguishable from a change in the other’s.
A final consideration is the platform layer. A combined chassis presents two interfaces, and the platform that consumes them has to be able to schedule between them. Where the platform cannot apply its own priority, the reservation on the device is the only control available, which is why it should be sized for the committed workload rather than for the average of the two.
Where the deployment carries commercial messaging, the operational expectations for consent and identification are described by M3AAWG and, for the North American market, by the CTIA. The signalling that carries the voice side is defined by RFC 3261, the cellular side by 3GPP, and the equipment framework by the ETSI standards catalogue.
Conclusion
A combined chassis works when the reservation is structural rather than statistical: ports and SIM groups assigned per workload, a channel budget that starts from the committed workload, and an acceptance test that measures each commitment while the other is at peak. Where both workloads carry commitments, or where each must be independently evidenced, separate hardware within one product family is the simpler answer and usually the cheaper one over three years.
The arithmetic that decides the question is a division. Channels needed for the committed workload, plus channels needed for the residue, compared against the chassis. Where the sum exceeds the chassis, the choice is more channels or separation, and the published configurations from the 4-port messaging model at $238.00 and the 4-port voice model at $260.00 upward make the second option inexpensive to evaluate.
Budget channels from the workload that has the commitment. Send your messaging volumes, call peaks and delivery commitments to service@telarvo.com, or review the published models on the SMS gateway solution pages.
FAQ
Can one gateway handle SMS and voice at the same time?
It can, provided the channels are reserved by port group rather than shared. Both workloads use the same cellular radios, so a call surge will delay messages unless the messaging workload has its own guaranteed channels. Reserve for whichever workload carries a commitment, then allocate the residue to the other and confirm it still meets its own requirement.
How many channels should each workload get?
Start from the workload with the tighter commitment and give it what it needs independently, then check whether the remainder satisfies the other. Where the two workloads peak at different times, the sum of their peaks overstates the simultaneous requirement; where peaks overlap, the sum is the budget. Establish which applies from traffic data rather than assuming.
Should SMS and voice run on separate devices?
Where both carry published commitments, or where an investigation must demonstrate that one workload did not affect the other, yes. Separation costs one device and removes the contention question entirely, and it makes each workload independently evidenced. Keeping both within one product family means the console conventions, log format and acceptance tests stay consistent.
What happens to messages during a call surge?
With a reservation, nothing: messaging keeps its own channels and latency is unchanged. Without one, messages queue behind calls and a time-bounded message such as a verification code may arrive after it has stopped being useful. The acceptance test that exposes this drives voice to maximum and submits a messaging batch at the same time, measuring latency against the commitment.