Voice clarity comparisons between gateways usually end in disagreement because the comparison is made by listening. Listening tests are useful for finding a fault and useless for choosing between two devices, because the result depends on the codec, the path and the person doing the listening.
This article sets out what actually determines perceived clarity, how codec negotiation and transcoding change it, how to measure rather than listen, and the protocol that produces a comparison two engineers can reproduce on different days.
What determines the perceived voice clarity of 4G VoIP gateways?
Delay, loss, jitter and the codec, in that order.
Perceived clarity is the result of the whole path rather than of the device, and the four factors that dominate it can each be measured independently.
Delay is the first because it changes how a conversation feels even when every syllable arrives intact, and the reference for end-to-end delay in speech applications is ITU-T G.114, which treats one-way delay up to 150 ms as acceptable for most applications with tolerance rising well above that where the application allows it. Loss is the second and produces the symptom users describe as words disappearing. Jitter is the third and produces the robotic bursts that a buffer can absorb at the cost of added delay. Codec choice is the fourth and sets how much the path can afford to distort before the result becomes noticeable.
Because these factors interact, a comparison that changes more than one at a time produces a result that cannot be attributed. That is the single most common flaw in gateway comparisons: two devices, different codecs, different paths, and a conclusion about hardware.
Codec negotiation and transcoding
Transcoding adds delay and a second opportunity for level mismatch.
Every conversion between codecs decodes and re-encodes the stream, adding processing time and a buffer, and the additions accumulate along the path.
The cheapest path is the one where the far end’s chosen codec is carried through without conversion. That outcome depends on what both ends offer and on what the equipment in between is willing to pass, which is why narrowing the offered set to what the connection actually supports often improves quality without any other change. The transport protocol that carries the media and reports its behaviour is defined in RFC 3550, and the profile that associates payload types with codecs and clock rates is specified in RFC 3551. Reading the two together explains why a call can be negotiated successfully and still sound poor.
In-band tone transport is a related detail. Where digits are carried in the media stream rather than signalled out of band, the mechanism is defined in RFC 4733, and a mismatch there affects how quickly digits are recognised rather than how clear the speech sounds. Separating that from a clarity problem saves an afternoon of codec work on a tone-handling issue.
How do you measure rather than listen?
Capture the reports the endpoints already exchange.
The media stream carries sequence numbers and timestamps, and its companion control messages report loss, jitter and round-trip estimates, which together give a measurable picture of the path.
The measurement procedure that works is unglamorous. Place a call of a fixed duration between two fixed endpoints, record the reported loss, jitter and round-trip figures, and repeat under identical conditions on the second device. The result is two sets of numbers taken over the same path, with the same codec and the same endpoints, which is the only configuration in which a comparison means anything.
Three details make the numbers comparable. Fix the call duration, because loss and jitter accumulate differently over long calls. Fix the codec, or record which one was negotiated so the difference can be attributed. And record the time of day, because a path that is clean at midnight and congested at noon will produce two different results from the same hardware. Signalling behaviour is defined separately in RFC 3261, and setup time should be recorded alongside media quality rather than inferred from it.
| Measure | What it explains | How to hold it constant |
|---|---|---|
| One-way delay estimate | Whether the conversation feels natural | Same endpoints, same path |
| Loss percentage | Disappearing words | Same call duration |
| Interarrival jitter | Robotic bursts | Same time of day |
| Negotiated codec | How much the path can afford to distort | Fixed codec set, recorded outcome |
| Setup time | Perceived responsiveness before audio starts | Same dialling sequence |
Network conditions at the installed position
The rack is not the bench.
Radio conditions, interference and antenna routing differ between a test bench and an installed position, and those differences affect the voice path as much as the messaging path.
The consequence for comparison is that devices should be measured where they will operate, not where they are convenient to test. A unit tested at headquarters may be compared against another unit tested in a rack, and the difference in conditions will be attributed to the hardware. Repeating both measurements at the same location, on the same day, removes most of that error.
Where the deployment is intended for several sites, measure at the site with the weakest conditions rather than at the most convenient one. The figure from the worst location is the one that determines whether the deployment meets its quality expectation, and it is also the figure that will produce the first complaint.
One last habit keeps the comparison honest: write down, before measuring, what result would change the decision. A protocol run without a stated threshold produces numbers and no conclusion, and the numbers are usually close enough that whoever prefers one device can read them favourably. Setting the threshold in advance is what makes the measurement decisive.
Keep the raw call records with the firmware version of each device. A later complaint about one call can then be checked against what was measured rather than against an average, and a firmware change that alters buffering behaviour is visible in the record rather than inferred from a change in results.
The effect of concurrent load
Quality measured on an idle device describes an idle device.
Voice clarity under load is a different measurement from voice clarity at rest, because concurrent calls, codec work and management traffic compete for the same processing.
The comparison protocol therefore needs a load condition, not just a quiet one. A useful pair of measurements is taken at the intended concurrency and at a defined proportion above it, which shows not only how a device performs but how it degrades. A device that holds quality at the intended load and degrades gracefully above it is easier to operate than one that behaves perfectly until it does not.
Where the deployment carries messaging on the same hardware, the load test should include message traffic, because the two workloads contend for the same cellular channel. That test is uncomfortable to run and it is the one that predicts the behaviour of the deployment during its busiest hour, which is when quality problems are reported.
How do you compare two devices fairly?
Same path, same codec, same duration, same load.
A fair comparison holds four variables constant and records a fifth, which is the negotiated outcome, so that differences can be attributed rather than guessed.
The variables are the path, the endpoints, the call duration and the load condition, and the recorded outcome is the codec that each call actually negotiated. Where the two devices negotiate different codecs, the media figures are not comparable, and the correct response is to constrain the offered set and repeat rather than to draw a conclusion. Network-side release reasons, when a call fails rather than degrades, are carried in standardised cause codes described in ITU-T Q.850.
A comparison protocol
The protocol fixes the variables before any measurement is taken, so that a difference between two devices can be attributed to a cause rather than to a change in conditions. It is short enough to run in an afternoon and specific enough to be repeated later against the same baseline.
- Fix the two endpoints and the path; do not change either between devices.
- Constrain the codec set so both devices negotiate the same codec.
- Record the negotiated codec for every call and discard results where it differs.
- Run a fixed call duration at idle and at the intended concurrency.
- Record loss, jitter, round-trip estimate and setup time for each call.
- Repeat at a defined load above the intended concurrency to see how each device degrades.
- Repeat the whole set at the same time of day before comparing.
The protocol produces a table rather than an impression, and a table can be reopened when the deployment scales. Where the comparison is being made to select a supplier, the protocol also makes the acceptance test obvious: measure the delivered unit against the measured sample under the same conditions.
Two additions make the result more useful over time. Record the firmware version of each device during the measurement, because a release can change buffering behaviour and therefore the figures without any hardware difference. And keep the raw call records rather than only the summary, because a later complaint about a specific call can then be checked against what was measured rather than against the average.
Where the deployment spans several markets, run the protocol in each of them. The radio conditions, the codec preference of the local network and the path to the destination all differ, and a comparison conducted in one market produces a conclusion that may not transfer to the next. The effort is bounded because the protocol is short, and the alternative is discovering that the device selected on headquarters measurements behaves differently where it is deployed.
Compare on measured numbers under identical conditions. Send your codec set, concurrency target and measurement results to service@telarvo.com, or review the published configurations on the VoIP gateway range and the VoIP gateway solution page. Telarvo publishes the SK VOIP gateway range and the GoIP models on its product pages, and the configurations referenced above come from those listings.
FAQ
How much latency is acceptable for VoIP?
ITU-T G.114 treats one-way delay up to 150 milliseconds as acceptable for most applications, with tolerance rising to roughly 400 milliseconds where the application allows. The recommendation describes categories rather than a single threshold, and the figure is end to end, so it includes everything from encoding to decoding. Measure the whole path rather than one hop. Record the figure per path rather than per device, because the two ends are rarely symmetrical.
Why does one gateway sound better than another with the same codec?
Because the codec is one of four factors. Delay, loss and jitter are determined by the path and by how each device handles it, and a device that buffers more aggressively may sound smoother while adding delay that the conversation notices. Measure the four separately before attributing the difference to hardware. The four together describe the experience. Keep the four figures in one record so that a later change can be attributed to the right cause.
Can we compare gateways using recorded audio?
Recordings are useful for subjective confirmation and weak as a comparison method, because they capture the path as it was at that moment. Use them to illustrate a measured result rather than to produce one, and always record the negotiated codec and the time of day alongside the recording. A recording without those conditions cannot be compared with another. Compare recordings only when the codec, the path and the time of day all match.
Does a better codec always improve clarity?
Not if it is converted somewhere in the path. A high-quality codec that is transcoded twice may produce a worse result than a simpler one carried end to end without conversion. The measure that matters is how many times the stream is decoded and re-encoded, which is why narrowing the offered set often helps. Fewer conversions also reduce delay. Count the conversions in the path before changing the codec set, because that count is the measurable part.
{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “How much latency is acceptable for VoIP?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “ITU-T G.114 treats one-way delay up to 150 milliseconds as acceptable for most applications, with tolerance rising to roughly 400 milliseconds where the application allows. The recommendation describes categories rather than a single threshold, and the figure is end to end, so it includes everything from encoding to decoding. Measure the whole path rather than one hop. Record the figure per path rather than per device, because the two ends are rarely symmetrical.”
}
},
{
“@type”: “Question”,
“name”: “Why does one gateway sound better than another with the same codec?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Because the codec is one of four factors. Delay, loss and jitter are determined by the path and by how each device handles it, and a device that buffers more aggressively may sound smoother while adding delay that the conversation notices. Measure the four separately before attributing the difference to hardware. The four together describe the experience. Keep the four figures in one record so that a later change can be attributed to the right cause.”
}
},
{
“@type”: “Question”,
“name”: “Can we compare gateways using recorded audio?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Recordings are useful for subjective confirmation and weak as a comparison method, because they capture the path as it was at that moment. Use them to illustrate a measured result rather than to produce one, and always record the negotiated codec and the time of day alongside the recording. A recording without those conditions cannot be compared with another. Compare recordings only when the codec, the path and the time of day all match.”
}
},
{
“@type”: “Question”,
“name”: “Does a better codec always improve clarity?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Not if it is converted somewhere in the path. A high-quality codec that is transcoded twice may produce a worse result than a simpler one carried end to end without conversion. The measure that matters is how many times the stream is decoded and re-encoded, which is why narrowing the offered set often helps. Fewer conversions also reduce delay. Count the conversions in the path before changing the codec set, because that count is the measurable part.”
}
}
]
}