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. Where something has not been proven, it says so in the same typeface as everything else — the section near the bottom is not an appendix, it is half the point.
There is no hardware modem bank. Both engines are software modems answering audio that Asterisk hands over a Unix socket, which is why twenty-four lines fit on one small 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 — none of ten attempts — which is why it is not the engine on every number, and why 14,400 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 failed every attempt, four out of four, 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. At that cap the answer side agreed 14,400 bps on six attempts out of six.
+1 610 922 1996 and +1 940 548 3638 are answered by the V.22bis engine at 2,400 bps, which any modem that can dial will train against. +1 857 342 5877 is answered by the V.32bis engine, which reaches 14,400 with a caller that speaks V.32bis and does not answer one that cannot. The three numbers are one pool of lines, not three tiers of service.
Thirty-two slots exist. Twenty-four is what this host will carry at once, and that number is measured rather than picked: every line has to feed the DSP every 20 ms for the whole call, and the host ran zero late frames at sixteen lines and at twenty-four, 426 late frames at thirty-one, and collapsed at thirty-eight. A slot is 5.2% of one core, so a larger host would carry all thirty-two. Until then the twenty-fifth caller gets a busy signal, on purpose, instead of twenty-four carriers degrading together.
Modem audio is not speech, and everything a PBX normally does to audio destroys it. Asterisk 22.10.1 is built from source here with app_audiosocket and res_audiosocket enabled and func_speex and chan_websocket compiled out.
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.
A telephone call placed from the public network to +1 610 922 1996 reached Asterisk, was answered, and produced 13.2 seconds of clean recorded audio:
661 RTP packets for 660 frames
Zero loss. That is the evidence that the signalling half of this works on the real telephone network rather than on a bench. That call was to the Pennsylvania number. The other two dial-in numbers are wired to the same handler, and neither has carried a call from the public network yet.
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.
A test without evidence is not a pass. These are the things this service cannot yet claim, listed because a company that publishes its own caveats is easier to believe about everything else.
Not yet demonstrated
Every speed figure on this page comes from software modems talking to each other through the audio path, with no carrier impairment at all. That is the control case, not a PSTN result. Real line noise, echo and a real V.42bis peer will move these numbers, and the honest expectation is downwards.
Not yet demonstrated
The transformation is built against a researched set of Netscape 3, Mosaic and MacWeb rendering failures and is checked automatically against them on every build. But nothing has been on a real 1996 screen yet, so that is a statement about the markup, not about how it looks.
Not yet demonstrated
Accounts live in a PAP secrets file on the server. The authentication is real; the accounting infrastructure an ISP would normally have is not there. MS-CHAPv2 has never been tested against a client.
Not yet demonstrated
It is compiled, running and producing files within its byte budget. No 1996 browser has decoded one. If a picture looks wrong to you, that is new information and worth an email.