Hilfe für Grundeinstellung Asterisk/Telekom benötigt

sonyKatze

Aktives Mitglied
Mitglied seit
6 Aug 2009
Beiträge
2,951
Punkte für Reaktionen
269
Punkte
83
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:

gehtdoch

Mitglied
Mitglied seit
3 Feb 2019
Beiträge
242
Punkte für Reaktionen
17
Punkte
18
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

AdamSapfel

Neuer User
Mitglied seit
27 Mai 2010
Beiträge
30
Punkte für Reaktionen
2
Punkte
18
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
 

gehtdoch

Mitglied
Mitglied seit
3 Feb 2019
Beiträge
242
Punkte für Reaktionen
17
Punkte
18
Man kann es sich auch einfach machen.
 

Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

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.
oder via

IPPF im Überblick

Neueste Beiträge

Website-Sponsoren


Kontaktieren Sie uns bei Interesse