Hilfe für Grundeinstellung Asterisk/Telekom benötigt

Da arbeitet wohl jemand an einer Neu-Definition von Nachtreten. ATO beschreibt ein Phänomen, dem man weiter nachgehen sollte. Der Ausweich auf TCP ist nämlich auch nur ein Workaround. Sein Phänomen könnte jederzeit nicht nur in UDP sondern auch in TCP auftreten.
ich habe ALG bisher noch nirgends benötigt. Wir haben als Provider easybell, Telekom, Entega Medianet (das ist hier ein lokaler Anbieter), da war das bisher immer ohne ALG möglich - und wir verwenden fast ausschließlich Draytek's.
Dann war meine Erklärung undeutlich … wenn Dein Anbieter den SIP-Header Contact wörtlich nimmt, dann hast Du mit einem Asterisk einfach nur Pech. Daher ignorieren viele Anbieter „IP-Adresse : Port“ in jenem Header und ersetzen diese durch die Angaben, die Du im received bzw. rport siehst. Die Frage ist daher: Warum macht das die Telekom Deutschland an diesem Anschluss anders?

Gegenbeispiel: 1&1 verlangt, dass im SIP der richtige Port seht. 1&1 schickt stur seine Antwort dorthin. Nur wenn man rport aktiviert, schickt 1&1 die Antworten auf den Quell-Port, also den Egress-Port des Routers. Später – bei eingehenden Anrufen – gehen diese auch mit rport stur an den SIP-Header Contact. Steht in diesem Header der falsche Port, dann hat man Pech. Das hat zwei Gründe: DrayTek verwendet in IPv4 einen anderen Port als der VoIP/SIP-Client; Nachrichten werden um-ge-mappt. Asterisk verwendet „received : rport“ nicht, um den eigenen SIP-Header Contact umzuschreiben. Weil Asterisk auch kein STUN kann, bleibt Dir nur das SIP-ALG (oder Port-Forwarding oder … oder …).

Über Ostern habe ich mir einen DrayTek Vigor2865 mit DrayOS 4.2 kommen lassen. Weil ich vor Ort war, konnte ich den WAN-Port in Wireshark mitschneiden. Ich fand keine Möglichkeit dieses Um-mappen zu vermeiden: Hoher Port, niedriger Port, Hardware-Beschleunigung … nix half. Klar, Port-Forwarding oder DMZ ginge. Ansonsten nimmt mein DrayTek das Datenpaket und schickt es auf einem anderen Port raus. SIP-ALG aktiviert, DrayTek schrieb die Request-Line und den Contact um, und 1&1 klappte „perfekt“. Spannend beim DrayOS SIP-ALG: Es achtet sowohl auf Quell- als auch auf Ziel-Port. In musste also nicht den Port auf den Quell-Port meines VoIP/SIP-Clients ändern, weil der Ziel-Port ja weiterhin 5060 ist.

Lange Rede kurzer Sinn: DrayTek macht nichts falsch. Jedenfalls sehe ich keinen Fehler. Es ist auch bei anderen Routern nicht unüblich, den Port um-zu-mappen. In Extremfällen macht das auch AVM FRITZ!OS – nur merken das Viele nicht und sind kurz nicht erreichbar. Daher, ATO, meine Tipps an Dich, DrayTek ist die falsche Baustelle:
  1. Öffne bei Asterisk einen Feature-Request, damit received und rport ausgewertet und der SIP-Header Contact umgeschrieben werden.
  2. Haue die Telekom Deutschland an – ja, die werden als erstes die Leitung durchmessen – und frage dort nach, warum dieser Anschluss bei SIP-over-UDP den SIP-Header Contact wörtlich nimmt. Ob das Absicht oder ein Konfigurationsfehler ist.
Wenn Du mal wieder vor Ort bist, kannst Du den Protokoll-Ablauf mittels diesem Post selbst nachbauen bzw. kontrollieren. Dank der XML-Dateien für die Contact-Abfrage und -Löschung solltest Du den Anschluss nach jedem Test wieder schnell freibekommen. Und so kannst Du bei einem Widerwort der Telekom Deutschland schnell prüfen, ob Tatsache oder nur Abwimmelung.

Auf jeden Fall würdest Du der Community einen großen Gefallen tun, wenn Du meine beiden Tipps beherzigen würdest. Ja, viel Arbeit.
die meisten leiten einfach den Port weiter ohne sich Gedanken darüber zu machen (wie es z. B. auch Herr Griebsch in seinem Blog-Beitrag beschreibt), was das bedeutet
Bedeuten … Problem ist – Stand heute, nach 23 Jahren – dass Asterisk (immer noch) nicht als reiner SIP-Client hinter einer Firewall gedacht ist. Klar kann man jetzt Firewalls verteufeln … oder anfangen dem Asterisk-Team zu verklickern, dass es eben auch Nutzer gibt, die nach außen nur einen SIP-Client und nicht auch noch einen SIP-Server brauchen. Aktuell geht mit Asterisk vieles zufällig dann doch. Die Frage ist, ob man als Betreiber immer rennen möchte, wenn es sich aus-ge-zufallt hat. Daher die (ganz) obigen Tipps, den Netzübergang so zu gestalten, dass nicht Asterisk diesen überwinden muss.
 
Zuletzt bearbeitet:
Haue die Telekom Deutschland an – ja, die werden als erstes die Leitung durchmessen – und frage dort nach, warum dieser Anschluss bei SIP-over-UDP den SIP-Header Contact wörtlich nimmt. Ob das Absicht oder ein Konfigurationsfehler ist.
Das kann ja wohl nicht Dein Ernst sein, zu empfehlen, von einer verschlüsselten auf eine unverschlüsselte Verbindung zu wechseln. Schräger geht wirklich nicht mehr. UDP gehört (nicht erst seit heute) schon längst abgeschaltet. TLS ist Standard und der muss funktionieren. Der funktioniert offensichtlich auch. Oder willst Du auch noch die Anforderungen resultierend aus der DSGVO z.B. leugnen? Alle Aktionen rund um SIP / UDP/TCP sind nicht erst seit heute reine Zeitverschwendung.

Es wäre viel sinnvoller, herauszubekommen, warum es bei TLS / NAT scheinbar keine Probleme gibt, als das zum Laufen zu bringen, was man seit Jahren schon nicht mehr haben will. Leider hast Du da nicht nachgeschaut. Das wäre nämlich die eigentlich interessante Frage gewesen.

Noch eine Anmerkung:
Ich fand keine Möglichkeit dieses Um-mappen zu vermeiden
Zumindest bei Linux / iptables / masquerading wird 1:1 verfahren (4.14er Kernel). Gerade mal nachgemessen (TCP und UDP). Habe ich mir im ganzen Leben noch nie Gedanken dazu gemacht. Welchen Sinn soll die Mapperei haben, außer Ärger zu verursachen?
 
Zuletzt bearbeitet:
  • Sad
Reaktionen: sonyKatze
Die Größe des Zeitfensters kannst Du selbst ermitteln, z.B. über
$ turnutils_natdiscovery -t -T 295 stun.antisip.com
Erhältst Du auf „Response 1“ ein „STUN receive timeout..“, sind 295 Sekunden zu groß für das Zeitfenster. Erhältst Du „Response 2“, hast Du einen passenden Wert für das Zeitfenster.

Wo bekomme ich turnutils_natdiscovery her? Ich habe coturn installiert was den Befehl aber nicht installiert
 
Man kann es sich auch einfach machen.
 
Hallo zusammen,

ich habe da auch meine liebe Not mit der Anbindung eines RaspberryPi mit FreePBX an einen Telekom Anschluss.
Ich habe laut Asterisk einen funktionsfähigen Trunk(Hauptleitung) kann aber nicht extern telefonieren.
Ich bekomme immer die Meldung All circuits are busy now ??
Ich habe mich da nach einer Videoanleitung in youtube gehalten aber leider ohne Erfolg.
Gibt es da eine aktuelle Anleitung oder Checkliste nach der man seine Konfig überprüfen kann?

Gruß
dnwalker
Hier ist eine Anleitung für Asterisk auf Raspberry Pi https://www.linuxmaker.com/asterisk-pbx/vorbereiten-der-firewall-fuer-den-einsatz-von-asterisk.html
Allerdings ist das noch ohne FreePBX und es ist ohne dieses typische Blackbox-Gesocks Fritzbox, Speedport, Zyxel sondern mit OpenWRT und Linksys plus DSL-Modem. Da hat mehr Freiheiten als mit den Blackboxes.
 
In der Outboundroute sicherstellen, dass die gewählten Nummern auch wirklich schon so ankommen, dass diese Regeln hier greifen können.
Guten Abend,
könntest Du mir etwas genauer erklären in welchen Reiter ich was eintragen muss?
Gruß von Stefan Harbich
 
Zuletzt bearbeitet von einem Moderator:

Zurzeit aktive Besucher

Keine Mitglieder online.

Statistik des Forums

Themen
245,856
Beiträge
2,241,270
Mitglieder
373,142
Neuestes Mitglied
FEY CARLOS
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.