Magenta Zuhause + Firewall (NAT) - Inbound Calls werden trotz STUN server abgewiesen

3-Finger-Harry

Neuer User
Mitglied seit
13 Jan 2020
Beiträge
103
Punkte für Reaktionen
5
Punkte
18
Als PBX ist FreeSwitch auf debian im Einsatz. Neben den drei Rufnummern der Telekom ist sipgate.de als Gateway konfiguriert. Während das Telefonieren über sipgate klappt, gehen bei der Telekom nur ausgehende Calls. Eingehende kommen aus den Netz der Telekom von Port 5060 und gehen bei der Firewall auf Port 5080. Bei Anrufen aus dem Netz von sipgate tauchen diese Ports aber erst gar nicht auf.

Vermutung: Die Telekom ignoriert den (eigenen) STUN server.

Aus /etc/freeswitch/vars.xml

Code:
  <X-PRE-PROCESS cmd="stun-set" data="external_rtp_ip=stun:stun.t-online.de"/>
  <X-PRE-PROCESS cmd="stun-set" data="external_sip_ip=stun:stun.t-online.de"/>
 
Für Telekom VoIP ist kein STUN Server notwendig. Dieser kümmert sich auch nicht um die verwendeten Ports.
STUN ist bei Telekom sogar kontraproduktiv, da die Plattform der Telekom eine automatische NAT Erkennung hat, die du mit der Nutzung von STUN behinderst.
 
Hast Du eine funktionierende Config parat?

PS: Die von der Fritzbox ausgelesene Config enthält auch den o.g. STUN Server
 
Ich nutze FreePBX nicht und kann nur von der Telekom Seite berichten.

Die FritzBox stellt auch in der Regel die Internetverbindung her und somit gibt es kein NAT.
 
3-Finger-Harry, benutzt Du SIP-over-UDP, -TCP oder -TLS? Hört sich nach UDP an.
eine automatische NAT Erkennung
Gibt es dazu irgendwo einen Thread oder eine komplette Auflistung? Ich habe das nämlich auch mal versucht nachzustellen und nach all meinen Tests war der Port im SIP-Header Contact jener, auf dem mich die Telekom anruft. Wenn es keinen Thread gibt, teste ich das mal systematisch und poste meine Ergebnisse.

Denn gerade FreeSWITCH hat das Problem nahezu völlig unsinnige Ports in diesen Header zu schreiben.
Eingehende kommen aus den Netz der Telekom von Port 5060 und gehen bei der Firewall auf Port 5080.
FreeSWITCH nutzt für den Contact-Header external_sip_port (normal: 5080) Lösche das mal in Deinen Konfigurations-Dateien. Wenn das nämlich nicht sitzt, kommt SOFIA_DEFAULT_PORT (normal: 5060) zum Zug.
 
3-Finger-Harry, kannst Du meine Fragen beantworten? Dann würde ich das versuchen mal nachzustellen. Poste bitte auch welchen Router Du verwendest. Nicht dass der noch ein SIP-ALG aktiv hat (und mehr kaputt als ganz macht).
nach all meinen Tests war der Port im SIP-Header Contact jener, auf dem mich die Telekom anruft. Wenn es keinen Thread gibt, teste ich das mal systematisch und poste meine Ergebnisse.
Spannenderweise kann ich das heute nicht mehr nachstellen. Egal was ich bisher im SIP-Header Contact sende (öffentlich, privat, falsch, Port richtig, Port 5060 oder falsch) und mache (UDP oder TCP), die Telekom Deutschland ignoriert das und sendet dorthin von wo aus ich sende. Wir hatten aber mal eine Meldung, bei der der Port nicht ignoriert wurde.
 
Ich zitiere ja so gerne aus der technischen Unterlage:

Nach drei eingegangen RTP-Paketen erkennt die Plattform den Datenstrom und baut ihrerseits zur selben Port (und IP) eine RTP-Verbindung auf. Die Erkennung basiert auf der abgehenden IP (aus dem SIP-Paket) des angesprochenen Telekom Gateways (aus dem SDP) und den angesprochenen Gateway-IP-Ports (SDP). Weitere Angaben im SDP (insb. TK-seitige IPs und Ports) werden ignoriert.
 
Muss sich mittlerweile geändert haben. Habe gerade einen Test gemacht (auf Basis von TLS) - komplett ohne NAT im SIP / SDP. In allen Headern oder auch im SDP standen also lokale IPs drin. War überraschenderweise kein Problem mehr. Das war vor längerer Zeit definitiv nicht so. Könnte natürlich auch daran liegen, dass ich bei diesem Test grundsätzlich vollständig ohne jedes NAT im SIP / SDP getestet habe - es war also konsistent "falsch" - während damals nur Teile falsch waren.
Allerdings: der Port hat natürlich gestimmt - aber das sollte am Ende des Tages eigentlich nicht relevant sein, weil ein Port alleine nicht weiterhilft ... .

Nicht genattete SIP/SDP-Header sehen aber für mich gruselig aus - daher bleibe ich bei der korrekten Vorgehensweise.

STUN ist übrigens nirgendwo involviert bei mir.
 
Zuletzt bearbeitet:
3-Finger-Harry, kannst Du meine Fragen beantworten? Dann würde ich das versuchen mal nachzustellen.
Danke für das Angebot. Dieses mal habe ich es dann doch noch selbst hinbekommen: Port-Forwarding raus aus. Für SIP-Signalling Port 5080 zulassen, sonst brechen Anrufe outbound nach ca. 30s ab.
 
KunterBunter, das ist wie ich oben schon erwähnte der Standard-Port für abgehende SIP-Registrierungen in FreeSWITCH. Leider aber nur im SIP. Auf der Transport-Ebene wird jedenfalls bei TCP ein anderer Port genutzt. UDP müsste ich nochmals testen. Ist aber völlig egal, was man hier nutzt, weil es die abgehende SIP-Verbindung beschreibt.
Port-Forwarding raus aus. Für SIP-Signalling Port 5080 zulassen
Was genau meint das: Hast Du irgendwas in Deinem Router geändert?
 
Eben diesen Port.

Wenn Du mehr Infos brauchst um ein HowTo zu basteln, sag Bescheid.
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.