Contents5 sections
How it worksARTICLE
Two Mobile Legs
A voice that sounds clean in the browser reaches a caller through mobile compression, sometimes twice. We modelled a call with AMR-NB on each mobile leg and G.711 between them: the agent stayed intelligible, short caller answers did not.
Costa4 min read
Short answer
When a call to a voice agent crosses two mobile networks, the audio is compressed with the AMR-NB codec on each mobile leg and carried as G.711 A-law between them, so it degrades twice. In our line model the agent's voice stayed intelligible, with an address, a price and a phone number transcribed word for word even at AMR 5.9 kbit/s with 3% frame loss. Short caller answers suffered: 'сто на сто' was heard as 'сто'. The agent is set to ask again when an answer looks odd, and the final check is always made on the customer's real line.
Key facts
- Line model: AMR-NB on each mobile leg, G.711 A-law transit between them.
- At AMR 5.9 kbit/s with 3% frame loss, an address, a price and a phone number spoken by the agent were transcribed verbatim.
- Short caller answers lost words: 'сто на сто' became 'сто', 'в ванной вообще' became 'вообще'.
- Each leg adds tens of milliseconds of delay, which goes into the response-time budget.
The demo sounds clean because it is a browser talking to a server over a fast connection, at full audio quality.
A customer calling from a mobile is not getting that. The voice is squeezed by the mobile network's codec on the way out, crosses the fixed network as ordinary telephone audio, and is squeezed again if the other end is also on a mobile. When an agent's line is reached through a mobile number, or forwarded to one, the audio is compressed twice in each direction.
The path we modelled
We built a model of that path and ran calls through it: AMR-NB, the narrowband codec mobile networks fall back to, on each mobile leg, and G.711 A-law, the standard telephone codec, in the transit between them. Then we made the network worse on purpose, down to AMR at 5.9 kbit/s with 3% of frames lost, and transcribed what came out at each end.
The runs used our Russian-language demo, so the examples below are in Russian with a translation. The demo has the same path as a listening mode, called "Two legs", so you can hear it rather than take our word for it.
What survives: the agent's voice
The agent's speech held up better than we expected. Even at 5.9 kbit/s with 3% frame loss, an address, a price and a phone number spoken by the agent were transcribed verbatim at the far end.
There is a reason for that, and it is worth keeping. The agent speaks in whole sentences, at an even pace, and says the important things with context around them: "the treatment for a two-room flat is four and a half thousand". A lost frame inside a sentence like that costs a syllable that the listener's ear, or a recogniser, restores from the words around it.
What breaks: short answers from the caller
The other direction is where it hurts. Callers answer questions briefly, and a short answer has nothing around it to restore from.
In our runs "сто на сто" (a hundred by a hundred, a size) came through as "сто". "В ванной вообще" (in the bathroom, mostly) came through as "вообще", which drops the only word that mattered. These are exactly the answers the agent needs most: sizes, rooms, yes and no, a number of something.
What we changed because of it
The agent is set up to ask again when an answer looks odd. If a size arrives as a single number, or a reply does not fit the question, it asks again rather than carrying a wrong value into the booking. "A hundred by what, sorry?" costs two seconds. A wrong size written to the order costs a second visit.
It is also one more reason the business keeps a transcript rather than somebody's memory of the call, which we wrote about in what was agreed on the phone.
Each leg also adds some delay, tens of milliseconds, which is small but not zero. It goes into the response-time budget alongside the parts described in where the second goes.
Why the real line decides
A line model is an approximation. It tells us what to expect and what to configure before the first real call, and it does not know your operator, your PBX, the forwarding rules on your number or the basement where half your customers seem to call from.
So the final check happens on your line: calls through your real chain, with the agreed scenarios, including the short answers. It is part of acceptance on our delivery page, next to response time and interruption. If you are not sure what that chain looks like yet, one number, two places is the place to start.
Questions this raises
- Will the agent's voice sound worse on a mobile phone?
- It will sound like a phone call, which is narrower than the browser demo. In our model it stayed intelligible even on a poor connection: an address, a price and a phone number came through word for word.
- What actually goes wrong on a bad line?
- Short answers from the caller. A two- or three-word reply has no context around it, so a lost frame can remove a word that matters. In our test 'сто на сто' arrived as 'сто'.
- Can a line model replace testing on our telephony?
- No. It is an approximation that tells us what to expect and what to configure. The final quality is checked by calls through your real chain, and that check is part of acceptance.