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 IPv6-Stand (Stand 2026-06-16, korrigiert): Liwest bietet KEIN natives IPv6 (techn. Support bestätigt). Die FritzBox macht 6to4 und annonciert ein 2002::-Prefix per RA ins VLAN1 → der FB-nahe VLAN1-Host hat damit (flatterhaftes) 6to4-v6: curl -6 zu ifconfig.co klappt (2002:5638:c211:…, eingeb. v4 86.56.194.17), aber ping6 Google v6 = 100 % Loss (Google-6to4-Relays abgeschaltet) = klassische 6to4-Teilerreichbarkeit. Intern NICHT durchgereicht: Mac mini (VLAN20 hinter ap1) hat kein v6 — ap1 macht kein RA/DHCPv6-PD auf den VLANs (TP4 v4-only), Branch-Switch (Omada) nicht v6-konfiguriert, Core-Switch (ALLNET) v6-Fähigkeit unklar. ⚠️ 6to4 relay-abhängig/flatterhaft (empirisch: Google-ping scheitert) → KEINE Basis für Echtzeit-Medien. Saubere Alternative bei Bedarf: 6in4-Tunnelbroker (Hurricane Electric, geroutetes /48). Details: Memory project-ipv6-state.

Zwei natürliche Kontrollexperimente (das Rückgrat der Diagnose)

Christophs nationale Videocalls = gut. Damit sind bei gleichem Upload / WLAN / Kamera/Low-Light ausgeschlossen: sein Upload, sein Roaming, seine Kamera-Bitrate als Alleinursache.
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.

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).
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.
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). ⚠️ Christoph-seitig v6 blockiert (Liwest kein v6; 6to4 untauglich für RT-Medien) → bräuchte erst 6in4-Tunnelbroker (HE) + 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.

18 KiB Raw Blame History Unescape Escape