In diesem Beitrag möchte ich ein paar Dinge erklären und klarstellen, die mir bei meinen stundenlangen Versuchen klar geworden sind.
Ganz kurz ein paar ganz kurze Erklärungen worüber wir sprechen:
NAT
Network-Adress-Translation wird in IPv4-Netzen genutzt, wenn mehrere Geräte hinter einem Router mit dem Internet verbunden sind. In meinem Fall befindet sich Asterisk/FreePBX hinter einem Router und ich möchte NICHT irgendwelche Ports extra am Router öffnen müssen, da dies ein Sicherheitsrisiko darstellt und Asterisk/FreePBX quasi ja nur ein “Client” ist, der sich bei der Telekom anmelden soll.
PJSIP
Asterisk/FreePBX unterstützt SRV-Lookups “so richtig” wie ich gelesen habe nur in den neueren Versionen, und dort so “out of the box” auch nur mit PJSIP. Der SIP-Treiber in Asterisk wird schon lange nicht mehr weiter entwickelt. Da wir bei einigen Systemen immer wieder mit PJSIP Probleme hatten, haben wir bislang immer weiterhin SIP eingesetzt, aber da die Telekom Ende Februar 2020 mit der “Telefonieanpassung” den SRV-Lookup (NAPTR) zwingend voraussetzt ist man quasi gezwungen die “Trunks” auf PJSIP um zu stellen.
Ein paar Hinweise gibt es dazu auch direkt bei der Telekom: https://telekom.de/telefonieanpassung
Vorsicht gilt hier übrigens bei Yealink-Telefonen!
Die von der Telekome gemachten Angaben funktionieren nicht!
Wenn man bei Transprot DNS-NAPTR auswählt, wie es die Telekom in ihrem Screenshot zeigt, registriert sich das Telefon nicht. Es genügt den Proxy wie im Screenshot der Telekom angegeben, anzugeben, und die Portnummern auf 0 zu stellen. Danach ist eine Registrierung erfolgreich und laut Telekom sind die Endgeräte “an der richtigen Plattform” registriert!
Gut, kommen wir nun zu der FreePBX/Asterisk-Konfiguration.
Zunächst einmal kursieren verschiedenste Informationen zu “was die Telekom unterstützt und was nicht”, meist von Leuten, die diese Information “IRGENDWO” her haben. Orientieren sollte man sich indes aber einfach an die Schnittstellenspezifikation der Telekom, die TR114.
https://www.telekom.de/hilfe/downloads/1tr114.pdf
Audio-Codec
Dort wird für VoIP zum Beispiel ausschließlich vom Codec aLaw und G722 gesprochen. Alles andere ist entsprechend unsinnig. Es ist aber im Grunde egal, ob man in FreePBX / Asterisk die anderen Codecs deaktiviert, weil sich Telekom/Asterisk sowieso im Vorfeld auf einen gemeinsam verfügbaren Codec einigen. Einzig interessant ist die Reihenfolge. Möchte man, dass bevorzugt G722 mit höherer Sprachqualität genutzt wird, sollte man den Codec auch an die oberste Stelle verschieben.
RTP-Port-Range
Zudem kursieren verschiedene Port-Angaben für RTP (Real Time Protocol) – also das Protokoll, mit welchem der Audio-Daten-Stream verschickt wird. Hierzu macht die Telekom keine Angabe! Die Standard-Einstellungen von FreePBX/Asterisk mit 10.000 bis 20.000 können beibehalten werden.
Benutzernamen und Kennwort
Man findet verschiedenste Angaben zu den Zugangsdaten, wo diese überall eingetragen werden müssen und wie diese lauten. Richtig ist jedoch ausschließlich folgendes:
Der Benutzername kommt bei PJSIP unter Allgemein in das Feld Username und das Kennwort wird unter Kennwort eingetragen, wobei das Kennwort aber nur beim SIP-Trunk notwendig ist! Bei den ALL-IP-Anschlüssen funktioniert die authentifizierung über die Internt-Einwahl und es genügt die Angabe des Benutzernamens, und der Benutzername ist dabei immer die Zugangsnummer
AOR-Daten
Die AOR-Daten sind meines erachtens nicht notwendig! Telefonie funktioniert ohne Probleme ohne diese Daten, sowohl beim SIP-Trunk, als auch beim All-IP-Anschluss
Registrierung aber keine eingehenden Gespräch
Beim SIP-Trunk hatte ich das Problem, dass FreePBX zwar registriert war, aber eingehende Pakete nicht ankamen. Mit Wireshark konnte ich herausfinden, dass überhaupt keine INVITE-Pakete von der Telekom ankamen. Nach weiterer Analyse habe ich herausgefunden, dass Asterisk für die Registrierung im VIA/Contac Header einfach eine völlig falsche, mir unbekannte IP eingetragen hatte. Nach etwas Googlen nach “Asterisk wrong Contact Header” stoß ich in einem Forumsbeitrag auf den Hinweis: Das Benutzen des Wildcard-Bindings ist problematisch!
Die Einstellung, wie sie überall im Internet zu finden ist:
ist entsprechend problematisch – dont do it! auch nicht wenn es vielleicht mal funktioniert, so wie da bei uns auch mal der Fall war – bis dann zum nächsten Tag…!
Nach dem ich die Einstellung geändert hatte, sodass das Binding an die IP der Schnittstelle des FreePBX-Systems geht:
und im Trunk den Transport erneut zugewiesen habe (weil der sonst zurück auf UDP umschaltet wenn das noch aktiviert ist):
kamen endlich Pakete auf der Anlage an! FREUDE! Zwar mit der Fehlermeldung unable to retrieve PJSIP transport aber nach einem Neustart von Asterisk war das gelöst, und plötzlich funktionierte die eingehende Telefonie endlich! Den Contact-Header habe ich nicht mehr kontrolliert, aber er muss ja jetzt stimmen, sonst kämen die Daten ja nicht an.
Beim ALL-IP-Anschluss hatte ich ein ähnliches Problem. Hier kamen die Pakete zwar am Router an, aber nicht auf dem Port, auf dem Asterisk sie rausgeschickt hatte, sondern auf Port 5061, den Port, den ich im PJSIP-Treiber unter binding angegeben hatte, was dazu führte, dass die Telefonie nur mit einer Portfreigabe von Port 5061 möglich war, was ein Sicherheitsrisiko darstellt und keine schöne Lösung ist.
Nachdem ich also auch bei einem All-IP Anschluss den hier zu verwendeten UDP-Transport an die IP der Schnittstelle des FreePBX zu binden, und nicht an die WildCard-Adresse, musste ich in den Trunks noch die Option Force rport wieder deaktivieren (siehe Screenshot), die vorher aktiv war. In den Channel-Treiber-Einstellungen muss zudem zwingend ein “Port to Listen On” (bei mir 5061, weil 5060 hier schon vom SIP-Treiber benutzt wird) eingetragen sein, da sonst keine Funktion mehr gewährleistet war, und die Anrufe wieder nicht rein kamen. Beim Telekom-SIP-Trunk hingegen war die Angabe des Ports unter TCP-Transport irrelevant und nicht nötig.
Ausserdem musste auch noch im Trunk unter allgemein der SIP Server Port heraus genommen werden
TLS statt TCP benutzen!
Am Ende hatte ich aber selbst mit dieser Konfiguration weiterhin Probleme, und ohne Portfreigabe im Router gab es immer wieder das Phänomen, dass die Rufnummern nach einer Zeit nicht mehr erreichbar waren. Schlussendlich zum Erfolg geführ hat, TLS zu aktivieren und als Transport zu verwenden! Ich kann nur jedem genau das empfehlen, dann werden auch keine Portweiterleitungen im Router nötig, die ein Sicherheitsrisiko darstellen!
Bei der Konfiguration mit TLS kommen zwar die Gespräche an, aber leider ist ausgehend kein Gespräch möglich.
Das kann viele Ursachen haben, ohne Detailinfos kann ich dazu natürlich nicht viel sagen.
Ausgehende Route an Position ein und zwei die Telekomnummer auf 3 ne Sipgate Nummer geht immer über Sipgate raus. Wenn Sipgate nicht hinterlegt Ansage „Derzeit sind alle Leitungen belegt …“
könnte an einer ungültigen rufnummernübermittlung liegen, aber ohne Logfile-Auszüge kann ich dazu nichts sagen.
Hi, danke für die Erläuterungen. TCP funzt bei mir. Wie sehen die Einstellungen für TLS dann aus?
Ich verstehe nicht ganz die Frage, meinst Du die transport-Einstellungen? Im Moment wird bei mir nur noch “ALL” bei allen Optionen angezeigt (weiss nicht mehr was ich da geändert habe), das steht bei mir entsprechend auf JA.