Call-Quality 🔍 Diagnose revidiert (Video/ISP-Strecke) + Handout

Anamnese mit Christoph kippt die frühere Roaming-These → Nebenfaktor.
Leitend: ratengebundenes Video über Geli→Christoph (CGNAT/Auslands-
Peering, Gegenlicht/Dunkel→Bitrate→Congestion-Kollaps; Jitter/Burst).

- Richtung geklärt: Engpass = Gelis Senderichtung (Handy-Uplink → ISP).
- 2 Kontrollexp.: Christophs nat. Video gut; Geli Cable→Fiber, Problem bleibt.
- Anschluss-Fakten: Geli 2.5/1.3 Gbit, v4=CGNAT (100.64/10), v6=nativ /56;
  Christoph kein Client-v6 (ap1 v4-only).
- IPv6 = billigster Hebel (nur Gelis v6 nötig; Telegram kann v6);
  Caveat CGNAT-Box vs Transit-Rohr → Abend-Messung entscheidet.
  SIP/Self-host nur Notnagel, TP3/Roaming nur Nebenfaktor.
- Handout (teilbar mit Geli): Schlauch-Analogie, 4 Knicke einfach erklärt,
  Telegram-Datensparmodus iOS/Android, Test + Ergebnis-Deutung.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/call-quality-diagnosis.md

@@ -0,0 +1,213 @@
+# Call-Quality-Diagnose & Handoff — Christoph ↔ Geli Video-Calls
+
+> **Zweck:** Self-contained Übergabe an eine separate Session. Enthält Symptom, **was bereits
+> ausgeschlossen ist (mit Messdaten + zwei natürlichen Kontrollexperimenten)**, die leitende
+> Hypothese und den Ausführungsplan.
+> Stand: 2026-06-16 (**revidiert** nach Anamnese mit Christoph). Ursprünglich im Rahmen von „TP6"
+> entstanden, das sich als **Nicht-QoS-Problem** entpuppt hat.
+
+---
+
+## TL;DR
+**Video-Calls zwischen Christoph und Geli** (Telegram u.a.) ruckeln/droppen, **andere Calls nicht**.
+Die zuerst vermutete **WLAN-Roaming-These ist auf Nebenfaktor herabgestuft.** Zwei natürliche
+Kontrollexperimente verschieben den Verdacht klar auf die **Geli-seitige ISP-Strecke**:
+- Christophs **nationale** Videocalls (vor Geli) liefen sauber → seine lokale Seite ist *nicht* die Wurzel.
+- Geli wechselte **Cable/DSL → Fiber** (jetzt FB 5530 Fiber) → Problem **bleibt** → ihre Last-Mile-Bandbreite ist *nicht* die Wurzel.
+
+→ **Leitende Hypothese:** Hochbitratiges Echtzeit-Video über die **AT↔Geli-Strecke** (kleiner Dorf-ISP
+`on-isp.net` / AS202245 Geroldsgrün, **CGNAT**, vermutlich dünnes/abends überlastetes Auslands-Peering)
+kippt unter schwer komprimierbarem Bild (**Gegenlicht/Dunkel → Bitraten-Spike**) in Loss/Jitter und
+lässt die **Congestion-Control kollabieren**. Roaming/Handover ist additiver Nebenfaktor.
+
+---
+
+## Symptom (vollständig)
+- Betroffen: **Christoph ↔ Geli**, **mehrere Messenger** (Telegram u.a.) → **nicht app-spezifisch**.
+- **Geli-Calls = 99 % Video.** Christophs **nationale Videocalls vor Geli liefen problemlos** (gleicher
+  Upload, gleiches WLAN, gleiche Kamera). → starkes Kontrollexperiment für „nicht Christophs Seite".
+- **Asymmetrie (Schlüssel):** Christoph ↔ andere = gut; Christoph ↔ Geli = schlecht. (Geli ↔ ihre
+  deutschen Freunde laut früherer Aussage ebenfalls gut.)
+- **Licht-Abhängigkeit (Schlüssel):** Gehäuft bei **Dunkelheit**; **Gegenlicht bei Geli** (helles
+  Fenster, dunkler Rest) erzeugt sichtbare **Artefakte** auch tagsüber. → zeigt auf **Video-Bitrate**
+  (Sensorrauschen/Kontrast schwer komprimierbar), nicht auf Bewegung.
+- **Bewegung** verschlechtert zusätzlich; **still sitzen = etwas besser, aber weiter mies**.
+- **Congestion-Signatur:** **Neuer Call = schlagartig besser, dann „nächster Abbruch vorprogrammiert"**;
+  **Kamera aus/ein hilft**, solange es „noch nicht zu arg" ist. → klassisch **bandbreiten-/ratengebunden**
+  mit kollabierendem Bitraten-Schätzer, **nicht** sauberer Pfad mit zufälligem Paketverlust.
+- **Jitter-/Burst-Signatur (neu, Schlüssel):** Stille **und/oder Standbild**, **verzerrter Ton („wie E-Gitarre")**,
+  danach **Turbo-Aufholen der letzten Gesprächsfetzen**. → Pakete werden **nicht nur verloren, sondern in
+  einem Buffer verzögert und stoßweise nachgeliefert** (Jitter/Queuing/Bufferbloat auf der Strecke).
+  E-Gitarre = Packet-Loss-Concealment des Codecs; Turbo-Catch-up = verspätet im Pulk angekommene Pakete.
+- **Richtung GEKLÄRT (neu):** **Christoph hört/sieht Geli deutlich schlechter; Geli hat es mit Christoph seltener.**
+  → dominanter Engpass = **Geli→Christoph**, also **Gelis Senderichtung (Upload)**.
+- **WLAN-Korrelat bei Geli (neu):** schlechter mit **Distanz zum AP** und an **schlecht ausgeleuchteten Ecken** —
+  konkret **draußen auf der Bank an der dicken Hausmauer** (weit/abgeschirmt + dunkel = WLAN-Uplink *und* Bitrate gestresst).
+- **WLAN-Architektur ist NICHT das Problem (neu, wichtig gegen Fehlfix):** Coverage gut, **keine Nachbar-WLANs**,
+  TX 100 %, Dual-Band. Der Engpass ist **nicht Design/Abdeckung**, sondern **Timing auf dem Uplink**:
+  (a) **Halb-Duplex/Airtime-Contention** (nur einer funkt zugleich; fallweise durch andere aktive Geräte, PS meist aus) → Jitter;
+  (b) **Retransmits** bei Distanz/Mauer/Bewegung → verspätet-im-Pulk = Jitter (Durchsatz sieht „ok" aus);
+  (c) **TX 100 % hilft nur Downstream** (AP→Handy) — der **Handy-Uplink** (Gelis ausgehendes Video) bleibt schwach,
+  v. a. hinter der dicken Mauer; (d) abgelesene **RSSI = Momentaufnahme**, verdeckt kurze **Spikes/Einbrüche**.
+- **„Seit Fiber generell schlechter" (Geli, subjektiv) — Confound (neu):** mit dem Fiber-Umbau zog der Router um.
+  Die **PlayStation** (per WLAN, **aber regulär ausgeschaltet** → kein laufender Call-Contention-Faktor) hat **beim
+  Gaming Aussetzer** → bleibt als **Indiz für WLAN-Schwachstellen** an ihrem Standort, nicht als Dauer-Ursache.
+  „Fiber schlechter" = der **Umbau/Router-Standort**, nicht die Leitung.
+- **Geräte-unabhängig (neu):** Geli Galaxy Note 10+ (test: A35), Christoph früher S22 → jetzt iPhone 16 Pro —
+  Problem über alle Wechsel hinweg → **nicht gerätespezifisch**.
+- **„Nie das Bandbreitenlimit gesehen" (Christoph) — Mess-Caveat (neu):** FB-Charts zeigen **gemittelte (Mean-)Werte**;
+  die tödlichen **Sub-Sekunden-Microbursts** (Video-Spikes, WLAN-Retransmits) tauchen darin **nie** auf →
+  **kein Freispruch** für transiente Sättigung.
+
+### Hardware-Timeline (beide Seiten, identische WLAN-Idee)
+- **Christoph:** FB 6660 + 1 Repeater (OG, LAN-„Mesh") → **2× Cudy (2×2)**. ISP = Liwest (DOCSIS), Upload ~10 Mbit.
+- **Geli:** FB 6660 + FRITZ-Repeater → Cudy → *(Glasfaser-Umstellung)* → **FB 5530 Fiber + Cudy**.
+  **APs = Cudy WR3600E** (Wi-Fi 6, Dual-Band 2.4+5 GHz), **TX 100 %**. ISP über alle Epochen konstant =
+  **`on-isp.net` / AS202245 Geroldsgrün**.
+- **Gelis Anschluss (FB-5530-Settings, 2026-06-16):** **2.5↓ / 1.3↑ Gbit** (Bandbreite endgültig kein Faktor).
+  **IPv4 = CGNAT bestätigt:** WAN-IP `100.72.62.31` ∈ **100.64.0.0/10** (RFC 6598), außen `94.154.138.11`.
+  **IPv6 = nativ öffentlich:** Prefix `2a0e:7a02:31c:3000::/56`, **kein CGNAT auf v6** (Prefix rotiert ~30 h → DDNS nötig).
+  DNS = Quad9 (`2620:fe::fe:11`) + ISP-EDNS0 (`37.60.7.2`).
+- **Christophs Anschluss (Check 2026-06-16):** **kein Client-IPv6** (Mac mini ohne globale v6, `curl -6` scheitert) →
+  ap1/TP4 ist **v4-only** (kein DHCPv6-PD); Liwest-v6 am FB unbestätigt. **IPv6-Pfad blockiert auf Christophs Seite.**
+
+---
+
+## Zwei natürliche Kontrollexperimente (das Rückgrat der Diagnose)
+1. **Christophs nationale Videocalls = gut.** Damit sind bei *gleichem* Upload / WLAN / Kamera/Low-Light
+   ausgeschlossen: sein Upload, sein Roaming, seine Kamera-Bitrate **als Alleinursache**.
+2. **Geli Cable/DSL → Fiber, Problem bleibt.** Damit ist Gelis **Last-Mile-Bandbreite** als Wurzel raus.
+   Was auf ihrer Seite konstant blieb: **derselbe Mini-ISP + CGNAT + die internationale Strecke** und die Cudy-WLAN.
+
+→ Schnittmenge beider Experimente = die **Geli-seitige ISP-/Peering-/CGNAT-Strecke** als gemeinsamer Nenner.
+
+---
+
+## Was bereits AUSGESCHLOSSEN / herabgestuft ist
+Messungen vom **Mac mini (Kabel, en0, VLAN20/INFRA, GW 10.40.20.1)**, 2026-06-16, **tagsüber im gesunden
+Zustand** (deshalb sauber — der Mehrwert liegt im Mitschnitt **WÄHREND eines miesen Abend-Calls**).
+
+| Hypothese | Befund | Urteil |
+|---|---|---|
+| Heim-Bufferbloat Christoph (Upload) | 3 Flows = 10.3 Mbit gesättigt → idle 12 ms, Vollast avg 17 / max 26 ms = A/A+ | ❌ kein Problem |
+| Generischer AT→DE-Pfad | heise.de: 20.7 ms / Jitter 1.6 ms / 0 % Loss (40) | ❌ Pfad (tagsüber) top |
+| Christoph → nächstes Telegram-DC | 149.154.167.50 (NL): 27 ms / Jitter 1.3 ms | ❌ Pfad (tagsüber) top |
+| CAKE / QoS | kein Bufferbloat-Spielraum | ❌ **nicht deployt** (wäre marginal) |
+| WARP / internat. Pfad | AT→DE tagsüber bereits 20 ms | ❌ **nicht deployt** |
+| S2S-VPN-Tunnel (BF-FB ↔ Geli-FB WG) | Messenger = Cloud-Relay, nicht im Tunnel | ❌ **nicht im Call-Pfad** |
+| Christophs lokale Seite (Upload/WLAN/Kamera) | **nationale Videocalls = gut** (Kontrollexp. 1) | ❌ keine Alleinursache |
+| Gelis Last-Mile-**Bandbreite** | **Cable/DSL→Fiber, Problem bleibt** (Kontrollexp. 2) | ❌ nicht die Wurzel |
+| **WLAN-Roaming/Handover** (ehem. Lead) | Cudy half *etwas*; still sitzen *etwas* besser, aber weiter mies; Hauptkorrelat ist **Licht**, nicht Bewegung | ⚠️ **Nebenfaktor**, nicht Wurzel |
+| ~~Gelis CGNAT/Dorf-ISP durch Asymmetrie entlastet~~ | **VOID.** Gilt nur, wenn der Flaschenhals ihr *Access-Link* wäre. Sitzt er im **internat. Peering**, laufen Gelis *innerdeutsche* Calls nicht drüber → Asymmetrie bleibt erklärt | ⚠️ **wieder im Spiel** |
+| Telegram-App-Bug/Codec | mehrere Messenger betroffen | ❌ entlastet |
+| ~~Christoph WLAN -76 dBm auf `install-10`~~ | `install-10` = Testnetz, nicht produktiv | ⚠️ Fehlmessung, ignorieren |
+
+---
+
+## Leitende Hypothese: ratengebundenes Video über die Geli-Strecke
+**Mechanik:** Echtzeit-Video-Congestion-Control (WebRTC/Telegram-artig) sucht die maximale Bitrate.
+Schwer komprimierbares Bild (Gegenlicht/Dunkel → Sensorrauschen + Kontrast) treibt die **geforderte
+Bitrate hoch**. Trifft das auf einen **engen/variablen Punkt der Geli-Strecke** (CGNAT-Session-Limit,
+abends überlastetes Auslands-Peering eines Mini-AS), entstehen **Loss/Jitter**; der Bitraten-Schätzer
+kollabiert und erholt sich nicht → genau das beobachtete „neuer Call kurz gut, dann Abbruch".
+
+**Warum das alle Beobachtungen erklärt:**
+| Beobachtung | Erklärung |
+|---|---|
+| Gegenlicht/Dunkel → Artefakte (auch tagsüber) | hohe Entropie → Bitraten-Spike → über den Engpass |
+| „dunkel" gehäuft | Sensorrauschen **+** Abend-Peak-Last (dieselbe Richtung) |
+| neuer Call kurz gut, dann Abbruch | Congestion-Control rampt in die Ratenwand, kollabiert, Reset hilft kurz |
+| Kamera aus/ein hilft | senkt Bitrate → entlastet Engpass = bandbreitengebunden |
+| nur mit Geli | nur dieser Pfad hat Mini-ISP + CGNAT + Auslands-Strecke; nationale Calls nicht |
+| Roaming nur Nebenfaktor | „still = etwas besser, aber mies"; „Cudy half *etwas*" |
+
+**Lokalisierung GEKLÄRT:** Christoph leidet stärker (hört/sieht Geli schlechter), Geli seltener →
+Engpass sitzt dominant auf **Geli→Christoph = Gelis Senderichtung**. Innerhalb dieser Richtung ist die
+Kette: **(1) Gelis WLAN-Uplink** (schwach an dicker Hausmauer/Distanz; Airtime nur fallweise, PS meist aus)
+→ **(2) hohe Video-Bitrate** (Gegenlicht/Dunkel) → **(3) CGNAT/Auslands-Peering**
+(abends). Die **Jitter-/Burst-Signatur** (verzögert-dann-stoßweise) zeigt: es ist primär **Queuing/Bufferbloat
+auf dieser Senderichtung**, nicht reiner Random-Loss.
+
+---
+
+## Ausführungsplan (für die separate Session)
+**Reihenfolge: erst beweisen, dann fixen.** Constraint: **passiv messen** während echter Calls
+(„cave: verändert den Datenstrom"); **kein iperf/Sättigen** während eines laufenden Calls.
+
+1. **Billige Sofort-Tests (heute Abend, ~0 €):**
+   - **Bitrate/Auflösung im Messenger deckeln** (z. B. Telegram-Datensparmodus) → wird's spürbar stabiler? = Mechanismus bestätigt.
+   - **Gelis Gegenlicht eliminieren** (Lampe von vorn, nicht Fenster im Rücken) → Artefakte weg/weniger?
+   - **Richtungstest:** beide notieren, wer wessen Aussetzer sieht (s. Lokalisierung oben).
+
+2. **Messen — was lokalisiert wirklich? (wichtig: Sniffer-Grenze)**
+   - **Ein Call-Sniffer NUR auf Christophs Seite lokalisiert NICHT.** Was bei dir ankommt, hat Funk + ISP +
+     Transit bereits vermischt → zeigt nur das **Symptom** (eingehender Stream ruckelt/verliert, mit
+     Zeitstempel + Relay-IP), nicht **wo**. Verbleibende Unsicherheit = **Gelis Funk-Uplink vs. Gelis
+     ISP-Pfad** (≠ Fix!). Dafür braucht es einen Messpunkt **auf Gelis Seite**.
+   - **Remote machbar & aussagekräftig:** MTR/Ping-Log **Mac mini → Geli-FB `94.154.138.11`**, **abends
+     unter echter Call-Last vs. Tageswert** (22.2 ms / 0.88 ms / 0 % Loss). Degradiert der Pfad abends →
+     **ISP/Peering** schuld. Bleibt er sauber, Call trotzdem mies → Engpass liegt **in Gelis Funk/Relay**,
+     nicht im Transit. (Misst nur bis zur CGNAT-Grenze, nicht in ihr LAN.)
+   - **Auf Gelis Seite ohne Infra, nur per Handy:** **Bufferbloat-Test** (z. B. waveform.com/tools/bufferbloat)
+     auf **Gelis Handy abends** → zeigt direkt, ob **ihr Uplink unter Last aufbläht** (Latenz steigt) =
+     Anschluss/Funk. Einmalig, kein Setup.
+   - **A/B-Verhaltenstest (Handout) schlägt passives Sniffen:** ändert kontrolliert **eine** Variable
+     (nah am AP / gutes Licht / Audio-only / tags vs. abends) → lokalisiert besser, weil es Ursache *isoliert*.
+   - **Roaming nur sekundär:** Cudy-Stationen (RSSI/TX-RX/Retries/Assoc-Events) bei bewegtem Call —
+     Cudy ≠ MikroTik → kein MikroMCP; Cudy SSH+`iw station dump` rein lesend, falls möglich.
+
+3. **Fix-Pfade (nach Lokalisierung) — Geli-Tal: nur dieser ISP oder schlechter Mobilfunk:**
+   - **(sofort, ISP-unabhängig)** Bitrate-Deckel (Telegram „weniger Daten") + **Ausleuchtung/kein Gegenlicht**
+     + **Position nah am AP** + Calls eher **tagsüber** (Peak meiden) + **Audio-only** bei Bewegung.
+   - **(WLAN)** Zusätzlicher AP/nähere Funkstation an Gelis üblichem Call-Platz → stärkerer **Uplink** dort;
+     Band/Position so, dass das Handy nicht am fernen AP „klebt". TP3/CAPsMAN-802.11r adressiert den Roaming-Nebenfaktor.
+   - **(App/Codec)** **A/B mit anderem Dienst** (WhatsApp/Signal) abends — andere Congestion-Control kann auf
+     schlechtem Link robuster sein. Billiger Test, evtl. echter Gewinn. (FaceTime fällt aus: Geli = Android.)
+   - **(IPv6 — billigster Hebel, braucht NUR Gelis v6):** **Korrektur:** Telegram **unterstützt IPv6** (DCs dual-stack,
+     früher expliziter „Use IPv6"-Schalter); frühere Annahme „kann kein v6" war falsch. Die **schlechte Richtung
+     ist Geli→Christoph** (ihr Upload), erster Sprung = **Gelis Handy → Telegram-Reflector**. Geht *dieser* Leg über
+     v6, ist **Gelis CGNAT auf genau der kaputten Richtung umgangen** — das braucht **nur Gelis v6 (vorhanden),
+     NICHT Christophs**. Da ihre FB das LAN bereits mit v6 versorgt, **läuft das evtl. schon / ist 1 Schalter entfernt.**
+     **Verify (kein Ausbau):** auf Gelis Handy `test-ipv6.com` (Score) + Telegram-Daten-Einstellungen auf v6-Option prüfen.
+     **Offen/zu verifizieren:** ob aktuelle Clients den **VoIP-Reflector** über v6 ansprechen (Messaging-zu-DC = ja, Call-Reflector = wahrscheinlich).
+     **Caveat:** v6 umgeht nur die **CGNAT-Box**, NICHT das **Transit-Rohr** — bei Abend-Peering-Stau hilft v6 nicht.
+   - **(ISP-Intervention, falls Transit/Peering der Stau ist):** kleiner Lokal-ISP = eher erreichbar; Abend-Congestion
+     + Peering nach AT schildern. CGNAT-Opt-out/öffentliche v4 nur nötig, falls v6-Weg nicht tragfähig.
+   - **(strukturell, TP10 — NUR Notnagel, kein Default):** eigener Medienpfad (WG-über-v6 FB↔ap1, dann self-hosted
+     Jitsi/SIP) **erst erwägen, wenn die Messung „Transit-Rohr" sagt** — also wenn auch v6 staut und der ISP nicht
+     hilft. Für den CGNAT-Fall **nicht nötig** (Gelis vorhandenes v6 reicht). Bräuchte dann Christoph-v6 (ap1 IPv6-PD) + DDNS für Gelis rotierendes /56.
+
+---
+
+## Benötigte Infos / Zugänge (von Christoph)
+- **Richtung der Artefakte** (wer sieht wessen Aussetzer) — der wichtigste offene Fakt.
+- **Cudy-Modell** + Zugangsweg (SSH/Web-UI/App, Creds) — für den sekundären Roaming-Check, beide Seiten.
+- **Anruf-Gerät** (Handy/Modell) — Client-seitige Korrelation, Kamera/Codec-Verhalten bei Low-Light.
+- Gelis **Fiber-Tarif** (Up/Down) + Bestätigung **weiterhin CGNAT** (`on-isp.net`).
+
+## Constraints / Caveats
+- **Passiv only** während echter Calls.
+- **MikroMCP** verwaltet die **Cudys nicht**.
+- **ap1 ist unverändert** — keine QoS-/Firewall-/Queue-Änderung appliziert (Details unten).
+- Tagesmessungen waren sauber, **weil im gesunden Zustand** — nicht als Entlastung des Abend-Pfads werten.
+
+## Zustand ap1 (zur Sicherheit dokumentiert — NICHTS wurde geändert)
+- Keine Queues, kein CAKE. **Fasttrack `*8` weiter aktiv.** Keine neuen Mangle-Regeln.
+- WAN-Egress aktuell = `bridge` → FB (10.40.41.254); masquerade `out-interface=bridge` (TP4).
+- ether1-Direkt-WAN bleibt vorkonfiguriert/down (gated auf TP10).
+
+## Querverweise
+- **TP10** (VPN/CGNAT) — jetzt **aufgewertet**: Gelis FB `94.154.138.11:52727` (Fiber, CGNAT), AS202245
+  Geroldsgrün; Hub-Spoke auf ap1 (Geli wählt ausgehend ein, PersistentKeepalive ~25 s). Memory:
+  `project_ap_vpn_bridge_blocker.md`.
+- **TP3** (WLAN/CAPsMAN, 802.11r/k/v) — Fix für den **Roaming-Nebenfaktor**, nicht die Wurzel.
+- `docs/research/routeros-capabilities.md` — Fast-Roaming-Konzept.
+
+## Messdaten-Anhang (Rohwerte 2026-06-16, Tageslicht/gesund)
+- Upload-Sättigung Christoph: 3 Flows × ~430 KB/s = 1.28 MB/s = **10.3 Mbit** (sustained).
+- Bufferbloat Christoph: idle 12 ms; Vollast avg 17.5 / max 26 ms (24 Pings).
+- AT→heise.de: min 19.3 / avg 20.7 / max 27.6 / stddev 1.6 ms, 0 % Loss (40).
+- AT→Telegram 149.154.167.50: avg 26.9 ms / stddev 1.3 ms (29/30); 91.108.56.130 = 173 ms (fernes DC, irrelevant).
+- BF→Geli-FB 94.154.138.11: avg 22.2 / stddev 0.88 ms, 0 % Loss (30); rDNS `nat-3.aigbng02.bng.on-isp.net` = CGNAT.
+  ⚠️ **Tageswert** — Referenz für den Abend-Vergleich, kein Freispruch.
+- Testnetz-Client (VOID): `install-10`, 5 GHz, WPA3-PSK, -76 dBm — nicht das produktive Netz.

docs/call-quality-handout.md

@@ -0,0 +1,131 @@
+# Videocall Christoph ↔ Geli — warum es hakt & was wir testen
+
+## In einem Satz
+Es ist **nicht ein** Fehler, sondern **mehrere kleine Engpässe, die sich stapeln** — und ein
+Live-Videocall verzeiht das nicht.
+
+## Das Bild: ein Gartenschlauch mit Knicken 🚿
+- **Ein** Knick im Schlauch → läuft noch.
+- **Mehrere** Knicke gleichzeitig **und** du drehst den Hahn voll auf (HD-Video) → es spuckt und stottert.
+- Kein einzelner Knick ist „die" Ursache. Die **Verkettung** ist es.
+
+## Warum ein Call so empfindlich ist (die 1/5-Sekunde-Regel)
+Netflix puffert 20 Sekunden vor, ein Download darf langsam sein. Ein **Gespräch** muss **jedes Häppchen
+in ~1/5 Sekunde** da sein — zu spät = wertlos. Darum gibt es keine sanfte Verschlechterung, sondern eine
+**Klippe**: genug Luft = perfekt, eine Winzigkeit drüber = Einbruch (Standbild, Roboterstimme, Turbo-Aufholen).
+
+**Und der Versatz, den ihr schon hattet (Bild/Ton >1 Sekunde auseinander):** Wenn Pakete verspätet und
+stoßweise ankommen, versucht die Gegenseite zu **warten und zu sammeln** (ein „Puffer"). Je mehr Stress,
+desto **größer wächst dieser Puffer** — bis Bild und Ton **um eine Sekunde oder mehr** auseinanderdriften.
+Der Versatz ist das sichtbare Zeichen, dass der Puffer verzweifelt gegen das Ruckeln ankämpft.
+
+---
+
+## Die einzelnen Knicke — einfach erklärt
+
+### 1. Dunkles / Gegenlicht-Bild frisst MEHR Daten (klingt verrückt, ist aber so)
+Ein Video wird nicht als ganze Fotos verschickt. Das Handy **beschreibt** das Bild und schickt vor allem,
+**was sich ändert**. Ein helles, ruhiges Bild ist leicht zu beschreiben → **wenig** Daten.
+
+Im Dunkeln sieht die Kamera schlecht und **verstärkt** das Signal — dabei entsteht **Bildrauschen** (das
+körnige Geflimmer). Rauschen sieht **zufällig** aus und **ändert sich ständig**, auch wenn sich im Raum
+nichts bewegt. Zufällig + ständig anders = lässt sich **nicht kurz beschreiben** → das Handy muss **viel
+mehr** Daten senden. **Gegenlicht** macht's schlimmer: das helle Fenster zwingt die Kamera, den Rest
+abzudunkeln → dunkler Matsch voller Rauschen neben einem grellen Fleck.
+
+Paradox: **Je mieser das Bild aussieht, desto mehr Daten will es senden** — und reißt die Leitung genau im
+falschen Moment voll auf. Schafft die Leitung das nicht, gibt das Handy Details auf → die **klobigen
+Klötzchen** (Artefakte).
+
+### 2. Gelis Internet: Fiber ist breit — aber nur bis zur Haustür
+Gelis Fiber kann auf dem letzten Stück **sehr schnell** sein (bis zu 1 Gbit möglich) — wie eine **breite
+Einfahrt**. Das Problem liegt **hinter** der Einfahrt:
+- Ihr **kleiner, lokaler Anbieter** muss den Verkehr aller Kunden auf die großen Autobahnen bringen — vor
+  allem **über die Grenze nach Österreich**. Dorthin hat ein kleiner Anbieter eine **schmalere Auffahrt**,
+  die sich alle teilen. **Abends = Stoßzeit = Stau.**
+- Dazu **CGNAT** (einfach): Statt Geli eine **eigene Adresse** im Internet zu geben, steckt der Anbieter
+  **viele Kunden hinter eine einzige geteilte Adresse** — wie ein Wohnhaus mit **einem gemeinsamen
+  Briefkasten**, an dem ein Portier alles sortiert. Jeder Datenschnipsel muss durch diese **eine gut
+  besuchte Kreuzung** (mehr Verzögerung, kann unter Last verstopfen). Und ein **direkter Draht** zwischen
+  Geli und Christoph ist so kaum möglich → der Verkehr macht einen **Umweg über die Vermittlungs-Server**
+  des Messengers.
+
+Kurz: Die breite Einfahrt hilft nichts, wenn die **gemeinsame Dorfstraße + die Grenze + die geteilte
+Kreuzung** die engen, vollen Stellen sind.
+
+### 3. WLAN: viel Bandbreite heißt nicht „immer pünktlich"
+Gelis WLAN ist eigentlich **gut aufgestellt**: ordentliche Geräte (Cudy WR3600E), **volle Sendeleistung**,
+2,4 **und** 5 GHz, gute Abdeckung, praktisch **keine störenden Nachbar-WLANs**. Trotzdem kann es einen Call
+überfordern — und das hat **nichts mit der Menge** an Bandbreite zu tun, sondern mit **Pünktlichkeit**:
+
+- **WLAN ist eine Funk-Sprechstunde, bei der immer nur einer reden darf.** Sind weitere Geräte aktiv
+  (TV-Stream, Tablet, Hintergrund-Download), müssen sich alle **abwechseln** → kurze Wartezeiten zerhacken
+  den Call-Takt (**Ruckeln**).
+- **Funk verliert ständig kleine Stücke und schickt sie nochmal.** Bei Distanz, dicker Mauer oder Bewegung
+  passiert das oft → die Daten kommen zwar an, aber **zu spät und im Pulk** = Ruckeln. Die „Bandbreite"
+  sieht in der Statistik trotzdem okay aus — der **Takt** ist kaputt, nicht die Menge.
+- **Wichtig, oft übersehen:** Die volle Sendeleistung am Router hilft nur **in eine Richtung** (Router →
+  Handy, also wie gut Geli **empfängt**). Das **Handy selbst sendet leise** (kleiner Akku, lässt sich nicht
+  aufdrehen). Für den Call zählt vor allem **Gelis Handy-Uplink** — ihr **ausgehendes** Video, genau die
+  schlechte Richtung! Der laute Router macht das **leise Zurückrufen des Handys nicht lauter**. An der
+  **dicken Hausmauer draußen** ist genau dieser Rückweg am schwächsten.
+- **5 GHz vs. 2,4 GHz:** 5 GHz ist schnell, kommt aber **schlecht durch Wände**; 2,4 GHz kommt weiter, ist
+  aber langsamer. Draußen an der Mauer landet das Handy auf einem **schwachen** Funkweg — egal welches Band.
+- **Zur Signalstärke am Router:** Was man da abliest, ist eine **Momentaufnahme**. Die Probleme sind kurze
+  **Einbrüche/Spikes** (sie dreht sich weg, der Körper blockt, kurzer Schwund). „-55 dBm sieht gut aus"
+  schließt **kurze Stürze auf -80** nicht aus — und genau die lassen den Call **kurz stocken**.
+
+### 4. Roaming — nicht nur beim Handy im Ausland
+Geli kennt „Roaming" vom **Mobilfunk** (im Ausland ins fremde Netz). Im **WLAN** heißt Roaming etwas
+anderes: Es gibt **mehrere Funkstationen** (Access-Points) im Haus, und das Handy **wechselt** beim
+Herumgehen von einer zur nächsten. Dieser Wechsel ist **kein nahtloses Gleiten** — das Handy muss sich am
+neuen Punkt **kurz neu anmelden**. Das dauert nur Sekundenbruchteile, aber **genau in dieser Lücke** fehlt
+dem Call ein Stück → Aussetzer beim Aufstehen/Gehen.
+
+---
+
+## „Qualität runter" — warum das hilft und was die Tests verraten
+Je höher Auflösung/Bildrate und je schwieriger das Bild (dunkel/Gegenlicht/Bewegung), desto **mehr
+Datenrate** braucht das Video. Senkt man die Qualität (oder schaltet die Kamera aus), sinkt die geforderte
+Datenrate → es passt wieder leichter durch die **engste Stelle**. Genau deshalb ist das ein **Diagnose-Werkzeug**.
+
+### Telegram „weniger Daten für Anrufe" einschalten
+Dieser Schalter weist Telegram an, für Anrufe **sparsamer** zu funken.
+
+**iPhone (iOS):**
+1. Telegram öffnen → unten rechts **Einstellungen**.
+2. **Daten & Speicher**.
+3. Bereich **Anrufe** → **„Weniger Daten für Anrufe"** → **„Immer"**.
+
+**Android (Galaxy):**
+1. Telegram öffnen → oben links **☰-Menü** → **Einstellungen**.
+2. **Daten & Speicher**.
+3. Bereich **Anrufe** → **„Weniger Daten für Anrufe"** → **„Immer"**.
+
+> Hinweis: Den **größten** manuellen Effekt bringen **Licht**, **Position** und notfalls **Kamera aus** —
+> die genaue Videoqualität regelt Telegram sonst automatisch.
+
+---
+
+## Was wir jetzt testen — 5 Minuten, kostet nichts
+
+**Geli:**
+1. **Weg vom Gegenlicht:** Licht von **vorne** ins Gesicht, **nicht** das Fenster im Rücken.
+2. **Nah am AP bleiben:** im selben Raum wie der Cudy testen, **nicht** draußen an der Außenmauer/Bank.
+3. **„Weniger Daten für Anrufe" = Immer** (siehe oben).
+
+**Christoph:**
+1. Beim nächsten miesen Call **Kamera kurz aus** → wird der **Ton** sofort sauber?
+2. Merken: **Uhrzeit**, **hell/dunkel**, **drinnen/draußen**, **in Bewegung?**
+
+**Beide ansagen:** Wer sieht/hört wen schlechter? (Erwartung: **Christoph hört/sieht Geli** schlechter)
+
+### Was bedeutet welches Ergebnis?
+- **Kamera aus → Ton sofort sauber:** Engpass ist die **Video-Datenrate/der Weg**, nicht der Ton selbst.
+- **Besseres Licht hilft spürbar:** das **dunkle/Gegenlicht-Bild** (Knick 1) ist ein großer Faktor.
+- **Näher zum AP hilft spürbar:** **Gelis WLAN-Uplink** (Knick 3) ist ein großer Faktor.
+- **„Weniger Daten" hilft:** es ist **bandbreiten-/datenraten-gebunden** (wir füttern zu viel in zu wenig).
+- **Tagsüber klar besser als abends:** der **Provider-Weg/Stau** (Knick 2) schlägt durch — das ist der Teil,
+  den wir lokal **nicht** kontrollieren.
+- **Selbst nah am AP, gutes Licht, tagsüber, nur Audio noch mies:** dann zeigt der Finger auf den
+  **ISP/CGNAT-Weg** → dort müssen wir ansetzen (Anbieter-Anfrage / direkter Weg), nicht am WLAN.