Dialling with a 2,400 bps modem? Use +1 610 922 1996. As of 25 August the Texas and Boston numbers answer V.32bis only, 4,800 to 14,400 bps, and will not train a modem that can only do 2,400.
Engineering
This page is for the reader who wants to know whether any of this is real. Every figure below was measured on the running system, and each one says what it is a measurement of — a number without its method is a number you cannot check.
There is no hardware modem bank. Both engines are software modems answering audio that Asterisk hands over a Unix socket, which is why thirty-two lines fit on one virtual machine instead of a rack. They sit behind one admission point, and neither can do the other's job, so the engine that answers is fixed by the number dialled rather than by the calling modem.
| Engine | Modulation | Line rate | Goodput | Train |
|---|---|---|---|---|
| modemd — spandsp | V.22bis | 2,400 bps | 275 B/s | 1.6 s |
| slmbridge — slmodemd | V.32bis | 14,400 bps | 1,444 B/s | — |
Goodput is application bytes per second on incompressible data. Neither figure is rounded up. The V.32bis engine does not answer a caller that can only do 2,400 bps, which is why it is not the engine on every number, and why 14,400 bps is a rate some callers reach rather than a rate the service delivers.
1,444 B/s is 11,552 bps of a 14,400 bps carrier — 80%. The missing fifth is V.42 LAPM framing, acknowledgements and the occasional retrain. 80% is the correct number for a reliable-mode link, and a service quoting 1,800 B/s off a 14.4k modem would be quoting the carrier rate and calling it throughput.
The same twenty kilobytes, as zeroes, moves at 9,979 B/s — 6.9 times faster. That is evidence that V.42bis compression is live and working, and it is the reason HTML does better than the incompressible figure suggests. It is not a speed this service can deliver on real content and it is not offered as one.
V.34 does not train over this path, even in a clean loopback with no impairment at all. Rather than ship a configuration that negotiates down unpredictably, both ends are capped at AT+MS=132,1,1200,14400, and at that cap the answer side agrees 14,400 bps.
That is held per number in the Asterisk database, which the dialplan reads when the call arrives and the operations console writes. It is deliberately not stated here: a page that named a speed per number would be a sentence pretending to be a switch, and it went stale every time the switch moved. The pool default is V.22bis at 2,400 bps, and there are thirty-two slots on the V.32bis engine out of thirty-two. The three numbers are one pool of lines, not three tiers of service.
Thirty-two slots exist and thirty-two is what LiteNet carries, so the enforced ceiling is the size of the pool. That is measured rather than picked: every line has to feed the DSP every 20 ms for the whole call, and a frame-lateness sweep on the hardware that is answering is what establishes how many can hold that deadline at once. It is re-run on any hardware change, and the ceiling does not move without one. The measurement is pessimistic on purpose — it runs both ends of every call on the one machine, roughly twice the DSP work real callers impose. The thirty-third caller still gets a busy signal, on purpose, instead of thirty-two carriers degrading together.
Modem audio is not speech, and everything a PBX normally does to audio destroys it. Asterisk 22 is built from source here with app_audiosocket and res_audiosocket enabled and func_speex and chan_websocket compiled out. A module that cannot be loaded cannot be turned on by accident.
The codec path is pinned to (ulaw) with transcode:prevent, and no DSP is ever allocated on the channel. A single transcode, or one pass of echo cancellation or noise suppression, and the carrier will not train at all.
transcode:prevent is the load-bearing half. Without it a codec mismatch is resolved rather than refused, and the call completes, sounds fine to a person, and carries no modem.
A modern news front page is 380 kilobytes. At 1,444 B/s that is four and a half minutes, and at 275 B/s it is twenty-three. The proxy is what makes the difference between a service and a demonstration.
| Page | Upstream | Delivered | Saved | At 14.4k | At 2400 |
|---|---|---|---|---|---|
| bbc.com/news | 380,079 B | 5,933 B | 98.4% | 4.1 s was 263 s | 21.6 s |
| en.wikipedia.org/wiki/Modem | 505,622 B | 24,703 B | 95.1% | 17.1 s was 350 s | 89.8 s |
| news.ycombinator.com | 34,863 B | 16,078 B | 53.9% | 11.1 s | 58.5 s |
| text.npr.org | 6,095 B | 2,794 B | 54.2% | 1.9 s | 10.2 s |
Hacker News reduces least, at 53.9%, because it is already almost entirely links with very little boilerplate to remove. The transformation cannot invent savings that are not there, and a table that only showed bbc.com would be selling you the best case.
When a carrier trains, the modem daemon writes the negotiated rate to /run/litenet/sessions/<your-ip> and removes it when you hang up. The proxy reads that file to decide how hard to cut. Without it the profile would be a guess, and the wrong guess in the generous direction costs a subscriber minutes.
Scripts and stylesheets are dropped, the document is re-serialised from a parsed tree so tables cannot come out unbalanced, and images are transcoded down or replaced by numbered links. It is emitted as HTTP/1.0 with an exact Content-Length, because a 1996 client has no chunked-transfer decoder and renders the hex length lines as body text.
The planning figure the proxy uses is ten bits per byte, then 80% — 192 B/s at 2,400 bps against the 275 B/s actually measured. Being pessimistic picks the leaner profile at a boundary and costs a subscriber some pictures. Being optimistic costs them twenty minutes, and they hang up.
Every number above is a measurement of a specific thing, and reading one as a measurement of a different thing is the easiest mistake to make here.
Read it carefully
The line rate is what the two modems agreed. The goodput is what a file transfer actually moves after framing and acknowledgements, which is about four fifths of it. Quoting the first as the second is how a modem gets sold.
Read it carefully
Not of your modem, and not of the number you dial. The answering side has to commit to a modulation before it can hear what the caller is, so the engine on a slot decides the speed and a faster modem simply trains down to it.
Read it carefully
98.4% is what one news front page gives up. A page that is already mostly links gives up half that, and the table above publishes both for that reason. There is no average worth quoting.
Read it carefully
Thirty-two is what the hardware answering today holds without a modem missing its twenty-millisecond deadline. It is not a property of the software, and it is re-measured rather than carried over when the hardware changes.