Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: TheLastSysop Newsgroups: comp.os.linux.misc Subject: Re: Redundancy/Survival Date: Tue, 02 Jun 2026 16:36:17 GMT Organization: The Null Device Restoration Society Lines: 112 Message-ID: References: <10v55mv$2co0n$1@dont-email.me> <10v6qg9$2ot19$2@dont-email.me> <10v8tsh$3ajmv$2@dont-email.me> <10vaorr$3r8c4$1@dont-email.me> <10vk256$27ab8$5@dont-email.me> <10vl3kr$2ii0i$1@dont-email.me> <10vmtdr$6c5k$1@solani.org> <71b3fmxhhh.ln2@Telcontar.valinor> <10vn00o$32aon$1@dont-email.me> Injection-Date: Tue, 02 Jun 2026 16:36:18 +0000 (UTC) Injection-Info: dont-email.me; logging-data="3230483"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX186l0zQAtBSOmxPr+a14SHpfkSAr3RiDeo="; posting-host="d100ee8f79d7efae5410fccadbdcc1df" Cancel-Lock: sha1:4NIn9ElItWnnyeNcB2ZIm3G7oxk= sha256:82xQKRBQdvtlhZJLpvUm5jiC7BN8TNJvriNqs6lgjnI= sha1:5rCJJ8adY0Hy0MepJMGNWVk1k0s= In-Reply-To: <10vn00o$32aon$1@dont-email.me> X-Mood: reasonably caffeinated X-Archive-Policy: please preserve the funny parts X-Operating-System: TempleOS-adjacent abacus cluster X-Newsreader: tin can + wet string 0.9.7 Xref: csiph.com comp.os.linux.misc:87376 >On Tue, 2 Jun 2026 12:22:46 -0400, InterLinked wrote: >On 6/2/2026 12:03 PM, TheLastSysop wrote: >>> On Tue, 2 Jun 2026 17:55:51 +0200, "Carlos E.R." >>> wrote: >>> On 2026-06-02 17:38, Marco Moock wrote: >>>> Am 02.06.26 um 01:12 schrieb InterLinked: >>>>> On 6/1/2026 9:40 AM, Rich wrote: >>> >>> >>> >>>>> My point was that copper POTS customers can get speeds in the 40s/50s >>>>> calling the same service, no problem at all, but I'm not able to do >>>>> that with my service being delivered over fiber. Dial-up Internet >>>>> speeds are actually *hampered* by fiber... how ironic is that? >>>> >>>> This is because the analog signal is being converter to a digital signal >>>> by an analog to digital converter - it does not interpret the digital >>>> data signal. With ISDN, this was't that faulty, as ISDN is line- >>>> switched. IP is packet-switched, so jitter is there and relevant. >>>> The VoIP phone signal is also transferred between different carriers, >>>> which means there might be codec conversions. >>>> >>>> TLDR: V.90 is intended for analog lines, not for any digital service. >>> >>> Huh, no, not fully correct. >>> >>> V.90 assumes the analog signal from the phone is converted to digital on >>> the spot, at the client's exchange. >> >> Right. The useful distinction is not "copper vs fiber" by itself, but whether >> the modem path is the old PSTN/PCM path V.90 was designed around. V.90 >> downstream assumes a digital server-side modem and a mostly-digital phone >> network with one final D/A conversion near the subscriber loop. >> >> Once the analog modem signal is created by an ATA/ONT and then packetised as >> VoIP, all the boring voice-service details start to matter: codec, jitter >> buffer, packet loss concealment, echo cancellation, VAD, transcoding, and >> clocking. Even if the access medium is fiber, the modem no longer sees the >> same >> sort of path. >> >> Practical things I would check, if someone actually needs dialup to work over >> such a line: >> >> * force G.711/u-law or A-law only, with no compression; >> * disable VAD/silence suppression and echo cancellation if the gear allows >> it; >> * give the ATA/ONT traffic decent QoS and avoid WiFi in that path; >> * try limiting the modem to V.34/33.6 rather than chasing V.90 speeds. >> >> If that still does not hold, the annoying answer is that the line is fine for >> voice but not a transparent modem circuit. > >Everyone here seems to be missing the point or did not fully read what I >said earlier. > >I have regulated "POTS over fiber" service and it uses private >facilities. There is no other traffic on the fiber, it's just voice. I >can get perfect connections at 33.6k that stay up forever and do not >drop. Also very good connections with low speeds (300 baud) that >normally see lots of corruption over VoIP. > >Jitter and latency are not the issues here. >The codec is not the issue here (it's G.711 ulaw, as it should be). >There is no compression. >The voice quality is excellent and basically identical to TDM. I have no >qualms with the quality of my service in general. I just dislike that >there's no common battery as with copper, and a few other things. > >All of these things would be problems with "over the top" VoIP, this is >not over the top VoIP, it is actually engineered very well. Over the top >VoIP, you would never get 33.6k connections that stay up forever, or >long 300 baud modem sessions with no corruption. > >I suspect (but have not confirmed) that the ONT is doing something weird >with V.90 handshakes. It could be as simple as DTMF false detection for >a signal in the handshake that screws up the V.92 negotiation and causes >it to fallback to 33.6 - except I know the ONT is configured for inband >from other stuff I have analyzed with telco techs in the past, so I >don't think that's it exactly... but maybe you get the idea. > >If I had the ability to swap out the ONT or further debug it for issues, >I'm sure I could make it work, unfortunately I don't have that kind of >access. Fair enough; if 33.6 is rock solid and low-speed data is clean, then I would stop treating it as generic bad VoIP and look specifically at the modem-relay and line-card behaviour in the ONT/softswitch path. A useful first split would be to make the modem less ambitious and see exactly which mode breaks: * disable V.92 and try V.90 only; * disable V.90/V.92 and force V.34; * try with/without V.42/LAPM and compression, just to separate carrier training from higher-layer negotiation; * if your modem can report it, log the final modulation, symbol rate, retrains, BLER, and disconnect reason. If V.34 is boringly stable but V.90/V.92 fails or falls back differently with small option changes, that points away from packet jitter and toward some feature in the access voice equipment: echo canceller, tone detector, gain plan, clock slip, DTMF/CNG/CED detection, or a vendor's idea of "modem passthrough". Unfortunately the fix, if that is the case, is probably on the provider side: a different ONT profile, different voice-port firmware, or a real copper/PCM path. From the customer side you may only be able to gather enough evidence to make the ticket land somewhere past first-level support. -- TheLastSysop "I survived the great rm -rf / rehearsal and all I got was this .signature."