đŸ”ș Helmut be.IP — Finaler Plan

Rudel-Expertenrat · 19.08.2026

🩞🩉đŸș

Einstimmig: PtP/PtMP ist NICHT der TĂ€ter.
Problem = FritzBox-Rufnummernzuordnung fĂŒr GerĂ€t 383.

🔑 Kernsatz (Tyto)

"Fragt nicht die be.IP 'hab ich gesendet?', fragt die FritzBox 'warum routest du 383 nicht raus?'"

📡 Tunnel starten (Copy-Paste)

ssh -N -o ServerAliveInterval=15 -o ServerAliveCountMax=3 -R 18023:192.168.178.23:22 -R 18080:192.168.178.1:80 -R 18443:192.168.178.1:443 tunnelfabi@46.225.123.163

PW: TunnelFabi2026!

Fenster offen lassen! Nyx kann dann be.IP CLI + FritzBox GUI.

0 Backup + Sicherheitsnetz ▶

⚠ Eingehend funktioniert = Sicherheitsnetz. Nicht als erstes riskieren!

1 đŸ”„ FritzBox: GerĂ€t 383 LÖSCHEN + NEU einrichten ▶

WAHRSCHEINLICHSTER FIX! Die FritzBox zeigt bei IP-Telefonen das "ausgehende Rufnummer"-Dropdown NUR im Einrichtungsassistenten, nicht nachtrÀglich beim Bearbeiten! Deshalb hast du es gestern nicht gesehen.

⚠ Das gleiche fĂŒr die anderen 2 GerĂ€te (850077 + fax1754) wiederholen wenn 383 funktioniert!

đŸș Kiro:

"Wenn 383 keine ausgehende Leitung zugewiesen hat, ist alles andere egal."

🩉 Tyto:

"Die FritzBox erkennt das INVITE nicht als 'GerĂ€t das ĂŒber MSN X nach draußen darf' → kein 100 Trying → tot."

🐝 Recherche-Biene:

"Die FritzBox zeigt bei LAN/WLAN-GerĂ€ten eine REDUZIERTE Bearbeitungs-GUI. Das Dropdown 'ausgehende Rufnummer' existiert NUR im Einrichtungsassistenten, nicht nachtrĂ€glich." (3CX-Forum: 13+ BestĂ€tigungen fĂŒr identisches Problem)

1b 📡 FritzBox Paketmitschnitt (Geheimwaffe!) ▶

Die FritzBox hat einen eingebauten Paketmitschnitt — damit sehen wir in 2 Min was die be.IP wirklich sendet!

Richtig: INVITE sip:ZIELNUMMER@192.168.178.1
Falsch: INVITE sip:383@192.168.178.1 oder INVITE sip:620@192.168.178.1

2 INVITE-Trace lesen (Nyx macht das) ▶

Falls Schritt 1 nicht reicht — Nyx liest den SIP-Debug-Trace aus:

Tytos Tipp: Mit einem Softphone an derselben FritzBox dieselbe Nummer wĂ€hlen → Ziffern-Diff zeigt den Fehler sofort.

3 Amtsholungs-0 Stripping ▶

Falls die fĂŒhrende 0 im INVITE mitgeht:

Die Auerswald schickt wahrscheinlich "0" + Nummer (Amtsholung). Die be.IP muss die 0 abschneiden bevor sie den SIP INVITE baut.

4 From/CLIP = gĂŒltige MSN? ▶

đŸș Kiro:

"Passt der From-User nicht zu einer gĂŒltigen lokalen Nummer, verweigert die FritzBox das Raus-Routen (Anti-Spoofing) — und antwortet gern gar nicht."

5 UDP + Port 5060 (Hygiene) ▶

Red Herring laut Rudel — eingehend funktioniert ja ĂŒber Transport=auto. Aber trotzdem sauber machen:

6 ⚠ PtP→PtMP (NUR als LETZTES!) ▶

⚠ KANN DAS FUNKTIONIERENDE EINGEHEND KILLEN!

Nur wenn 1-5 nichts bringen, und nur mit Backup!

🩉 Tyto:

"NICHT den 'Erste Schritte'-Wizard. Der ĂŒberschreibt gesetzte Felder mit Defaults — das ist die wahrscheinlichste ErklĂ€rung, warum euer CLI-Setter 'silent failed'."

📋 Quick Reference ▶
? Warum widerspricht das Rudel der PtP-Theorie? ▶
"Wenn PtP der Killer wĂ€re, wĂŒrde die be.IP gar keinen vollstĂ€ndigen INVITE bauen können — sie wĂŒrde auf Ziffern warten. Aber der INVITE GEHT RAUS, also hat die be.IP die Ziffern komplett eingesammelt. → Der ISDN-Layer arbeitet in BEIDE Richtungen."

PtMP ist bei 3 einzelnen MSNs trotzdem die korrekte Einstellung — nur fixt sie nicht das Ausgehend-Problem. Nicht daran heute Abend verbluten.

Korrektur: Das "eingehend auf 383"-Log kam aus dem be.IP Monitor, NICHT aus der FritzBox. Die FritzBox sieht den ausgehenden Anruf GAR NICHT.