diff --git a/docs/call-quality-diagnosis.md b/docs/call-quality-diagnosis.md new file mode 100644 index 0000000..4287cc5 --- /dev/null +++ b/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. diff --git a/docs/call-quality-handout.md b/docs/call-quality-handout.md new file mode 100644 index 0000000..e544ae0 --- /dev/null +++ b/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.