wenn man bei der Telekom einen SIP-Trunk hat, tun die ja alles um Ihr eigenes Blech als Telefonanlage und sogar Router zu verkaufen. Hier geht es im speziellen um das SIP-ALG, was dazu führt, dass manchmal die Verbindung refused wird und die Telefonie tot ist.
Ich weigere mich aber hartnäckig irgendwelches Blech von der Telekom zu kaufen - wie die Telekom bemerkt hat, telefonieren wir auch ohne ihr Blech
Deshalb mal zwei Fragen:
a) Mein Router ist ein aktueller Ubuntu-Server - ich habe jetzt recherchiert, dass wenn nf_nat_sip deaktiviert wird, ist auch SIP-ALG deaktiviert - kann das vielleicht jemand bestätigen. Was ich bisher sehe, dass die Telefonie einwandfrei funktioniert, kann aber noch nicht sagen, ob es jetzt die Lösung für meinen Router ist.
b) Ist eigentlich keine Frage … aber mal als Gedanke für Pascom-Leute: In der Anlage läuft Icinga, ich werde mir hier einen Eventhandler bauen, der die Telefonie neu startet, wenn ich wieder folgende Meldung habe:
[Apr 17 09:32:54] ERROR[22870]: tcptls.c:895 ast_tcptls_client_start: Unable to connect SIP socket to 217.0.15.67:5060: Connection refused
Mir persönlich ist es egal, ob ich evtl. bestehende Gespräche kappen würde, aber selbst das könnte man vorher überprüfen und ggf. dann neu starten, aber wenn schon ein Fehler vorliegt, kann ich auch neu starten.
Wir haben auch Probleme mit dem SIP-Trunk der Telekom und Asterisk. Zwischen unserer pascom classic und Internet sitzen zwei Cisco Firewalls und der Lancom Router der Telekom. Wir haben überall SIP-ALG ausgeschaltet aber trotzdem immer mal wieder Probleme. Wir haben dafür das Asterisk logging so umgestellt, dass alles gelogt wird. Ich habe einen Python Dienst geschrieben der das Logfile mitliest und bei bestimmten Einträgen reagiert.
Am meisten treffen uns solche timeouts
[Apr 19 06:21:40] NOTICE[11341] chan_sip.c: -- Registration for 'UNSERETELNUMMER@reg.sip-trunk.telekom.de' timed out, trying again (Attempt #3)
Treten die auf starte ich den asterisk Dienst neu. Es gibt auch noch andere Meldungen wo ich über das Asterisk cli nur ein sip reload mache. Das funktioniert so weit ganz okay. Leider hatten wir vor ein paar Wochen einen Fall wo die Telefonie tot war ohne, dass wir es mitbekommen haben. Beziehungsweise es gibt nur noch in eine Richtung.
Hier im Büro hat die Anlage durch die Anlaufschwierigkeiten kein besonders gutes Standing. Auch wenn es zur Zeit sehr gut läuft.
Dazu kommen dann noch die Probleme mit dem Desktop Client. Am Anfang ist er sehr oft abgestürzt und wir hatten Probleme mit den Headsets. Das ist besser geworden und ich finde die Evolution des Clients auch beeindruckend aber mit der 17.07 habe ich das Problem, dass Kollegen die per VPN arbeiten plötzliche Audio Probleme haben wenn intern telefoniert wird.
Vielleicht könne wir in diesem faden m,al Telekom SIP Trunk spezifische Probleme und Lösungsansätze sammeln.
Hallo Crapp,
ja, gerade war die Telefonie mit dem SIP-Trunk wieder tot. Warum kann ich noch nicht sagen … zeitmangel
Auf jeden Fall habe ich nicht den gleichen Fehler. Fakt ist, diese Probleme treten nur mit dem SIP-Trunk auf. An anderer Stelle nutzen wir die Pascom auch, allerdings noch mit ISDN - da gibt es NULL Probleme.
den ausgehenden Registertimeout kann ich mir leider nur durch Netzwerkprobleme erklären, sollte SIP ALG an allen beteilgten Routern+Switchen deaktiviert sein und transport=tcp verwendet werden, dann weiß ich leider nicht wonach man suchen sollte (ohne einen Netzwerkmitschnitt für das SIP Signaling anzufertigen und für die Ausfälle auszuwerten).
Das einseitige, im speziellen nur eingehend nicht funktionierende Problem ohne Warnungen im Monitoring im Falle Telekom ist aber in der Tat gegeben und sollte mit den kommenden Hotfix Versionen behoben werden.
Die Telekom scheint als so ziemlich einziger SIP Provider häufiger (hängt gefühlt vom Bundesland ab, meist aber so 1x die Woche) des öfteren den Zuständigen Host über die Namensauflösung zu ändern. Der derzeitig eingesetzte Asterisk registriert sich dann zwar auf der neu aufgelösten IP, führt aber den Peer für das Telekom Amt fälschlicherweise unter der alten IP weiter. Deswegen können dann eingehende Anrufe leider keinem Amt zugeordnet werden (in der Asterisk CLI finden sich dann Zeilen mit “no-auth-in” wieder).
Ein SIP Reload (Neustart des Asterisk ist nicht notwendig) “zieht das Peer dann wieder gerade”.
Solltest du verständlicherweise nicht bis zum nächsten Hotfix warten wollen, kann dir unser Support auch ein Skript+cronjob zur Verfügung stellen. Das erkennt zumindest diesen Missstand und führt dann den “sip reload” aus.
ich freue mich erst mal zu hören, dass ihr an dem Problem arbeitet und es dafür einen Fix geben soll. Bei diesem no-auth-in macht mein Script zur Zeit auch nur ein sip reload von dem her bin ich da schon mal glücklich. Ich kann auch eure Beobachtung unterstreichen, dass es mit den Server Wechsel bei der Telekom zu Problemen bei Asterisk kommt.
Wird der Fix mit der 17.08 kommen oder eher später?
das weiß ich leider nicht und müsste ein Entwickler beantworten. Da unsere Entwickler aber den Hotfix aktuell testen, vermute ich, das alles was ab KW 18 veröffentlicht wird den Hotfix beinhaltet. Genauer kann das leider nur einer unserer Entwickler beantworten.
es gibt mittlerweile ein server plugin Script, welches das ganze lösen sollte. Wenn wir hier ausreichend Feedback erhalten haben, liefern wir es in den Release Versionen mit aus. Vorab gerne über den Support beziehen.
Hallo,
muss man das besagte Script in der 18er Version noch “aktivieren”, oder in einen Crownjob einbinden? Es findet sich ja unter Scripte, dennoch haben wir, wie beschrieben Wöchentlich ausfälle.
Das Server Plugin Script wird alle x Minuten automatisch ausgeführt sobald es ein Telekom Amt (welches unter Verwendung der Vorlage angelegt wurde) existiert. Man müsste den SIP Traffic von/zur Telekom mal mitschneidne und analyisren, ggf liegt ein anderes Problem vor. Eine derat Tiefgreifende Analyse kann ich an dieser Stelle jedoch leider nicht anbieten.
Aus der Erfahrung heraus könnte es an
temprorärer nichterreichbarkeit der Telekom und überschreiten der registerattempts liegen
WAN IP Wechsel / Zwangstrennung dazwischen
DNS Cache Fehler (DNS Server der die TTL der Einträge u.U. nicht richtig weitergibt)
Hallo,
ich stelle mir einfach die Dumme frage… Die Pascom weis das Telekom Ämter angelegt und schon mal verbunden waren, die Pascom registriert einen Ausfall und schickt eine mail. Bevor man nun neu Verbindet könnte man ja ein “sip reload” machen.
Wenn alle X Minuten das Script ausgeführt wird, wäre natürlich die Frage wie lange das X ist. Denn wenn ich das richtig gelesen haben, 10 versuche alle 20s, sind Standard bei registerattempts. Macht 3min, 20s.
Hallo,
die Probleme treten immer noch auf. Es wird Request Send angezeigt, bei der Telekom kommt aber keine anfrage an, das ergibt sich aus einem Log der Telekom. Internet Verbindung besteht, Easybell keine Probleme.
Sollte es an der Firewall liegen so sollte ja eigentlich nie eine Verbindung möglich sein.
hat der Anschluss eine Feste IP? Sollte diese Wechseln wird hier ggf die Connection nicht richtig gelöscht und die Pakete gehen noch mit der alten raus.
Ansonsten ist in der sip.conf der Default Wert “registerattempts” auf 20 gesetzt, d.h. nach ca. 20x20Sec (6min30Sek) hört der Asterisk Registrierungsversuche abzusetzen wenn keine Antwort oder nur Ablehnungen erfolgen. Nach dieser Zeit sendet die Anlage wirklich keine Registrierungsversuche mehr zur Telekom (der Status sollte aber auch nicht mehr Request send sein zu diesem Zeitpunkt).
Den Wert kann man über die Systemeinstellungen beispielsweise auf 100 setzen:
Hierzu bitte in den Systemeinstellungen unter sys -> asterisk -> configure -> sip -> file folgenden Wert eintragen:
Key: registerattempts
Wert: 100
Im Anschluss die Telefoniekonfig anwenden.
Mittels sngrep oder tcpdump kannst du ja tcp 5060 zur/von der Telekom mitschneidne, dort sieht man dann die Registrierungsversuche. Sind diese hier zu sehen und die Telekom sieht nichts, dann lügt entweder die Telekom oder (was wahrscheinlich ist) das Problem ist doch dazwischen und damit am ehesten am Router zu suchen.
Hierzu nochmal das best practice bei Telekom Ämter:
SIP ALG
am pascom 18 Interface anlassen, am Router und alles andere zwischen WAN und TK deaktivieren
DNS Server
nur einen direkten Telekom DNS Eintragen, das ist zwar nicht die direkte Empfehlung der Telekom, aber wenn man den Lancom einträgt frägt dieser auch mal den einen mal den anderen Telekom DNS Server, die zeitweise unterschiedliche SRV Einträge zurückgeben. Dadurch registriert sich der Asterisk am vom jeweils anderen übermittelten Host und “flappt” zwischen den beiden (und keiner funktioniert richtig). Interne DNS Server (AD) können u.U. die TTL der DNS Einträge falsch aus dem Cache weitergeben bzw verwenden mit ziemlicher Sicherheit selbst auch wieder mehr als einen DNS Server.
Optionsanpassung (sollte in kommenden Versionen im Template landen)
qualifyfreq=270
In den Optionen der Accounts (als eigenständige Zeile) setzen. Hintergrund: ohne Qualify kann der Lancom oder sonstig eingesetzte Router die TCP Connection Resetten wenn wenig los ist. Der Asterisk registiert sich bei einem TCP Session Reset nicht neu, was die Telekom in diesem Fall jedoch erwartet. Mit Qualify senden wir OptionPakete die Telekom eigentlich nicht möchte (alle 30 Sekunden im Default), hier kommt es manchmal dazu das die Telekom nur noch leere TCP Ack Pakete ohne SIP Content zurückschickt, woraufhin der Asterisk um Retransmission bittet und die Session bis zum nächsten neuaufbau nicht mehr zu gebrauchen ist. Schöner ist hier eigentlich eine Art SIP Ping zu implementieren, das Planen wir auch künftig sobald möglich zu implementieren.
registerattempts
Die Registerattempts in den Systemeinstellungen auf 100 (default ist 20) setzen:
Hierzu bitte in den Systemeinstellungen unter sys -> asterisk -> configure -> sip -> file folgenden Wert eintragen:
Key: registerattempts
Wert: 100
Das hilft wenn der Anschluss wegen Zwangstrennung oder ähnlichem mal länger als 6 Minuten nicht erreichbar ist. nach diesem Wert mal 20 Sekunden stellt der Asterisk seine Registrierungsversuche ein wenn diese nicht oder ablehnend beantwortet werden.
Wenn man obige 4 Punkte berücksichtigt und keine wechselnde WAN IP Addresse am verwendeten Anschluss hat, sollte es funktionieren. Zumindest hab ich bei Installationen bei dennen all dies berücksichtigt wurde keine Probleme mehr vernommen.
Hallo erstmal danke für die Rückmeldung!
Ich hab es angepasst (DNS 217.0.43.49), wir haben ne feste IP, verstehe aber manches Verhalten immer noch nicht. Nach der Anpassung habe ich den Telefondienst neugestartet. Die T-Nummern wollten sich nicht registrieren, sip reload brachte keine Abhilfe. Nach ~15 versuchen Telefondienst erneut neu gestartet… alle Nummern registrierten sich sofort.
Gäbe es zwischen Telekom und Pascom noch ein Problem, warum wird das nach einem Neustart des Telefondienstes behoben?
Der ganze wumps ist so unstrukturiert fehlerhaft das man keine Linie rein bekommt wo es hakt. Dabei Funktionieren andere Anbieter ohne Probleme. Im anderen faden gibt es ja auch drei weitere Personen die zu Kämpfen haben, vielleicht kann man das mal irgendwie zusammen schieben wo was für die Telekom geändert werden muss. DNS geht ja nicht über die Web Oberflächen…
Hallo, hat hier jemand Erfahrung mit dem SIP Trunk Pure der Telekom? Die best practice sehe ich gerade machen an einem normadischen, standortunabhängigen Anschluss recht wenig Sinn, oder? Bei uns läuft die Anlage im RZ mit einer öffentlichen IP und es kommt immer wieder zu Problemen, die ich auch hier gepostet habe: Anrufrouting mehrerer Ämter zu mehreren Standorten
Einen öffentlichen DNS Server der Telekom der funktioniert habe ich nicht (mehr) gefunden? Das DNS Thema würde aber Sinn machen, weil es immer mal wieder ganz “schlechte” Tage gibt, an dem der Kunde über massive Störungen klagt die dann am nächsten tag wieder besser sind.
Der Trunk selber hat sich überhaupt nur registrieren lassen, wenn SIP-ALG auf dem IF der Pascom aus ist, blieben noch die SIP-Optionen, die sind aber auch eher NAT/SIP-ALG Dingen geschuldet, oder?
ja der Wert muss erst hinzugefügt werden. Bei der 18.11 ist das Verhalten aber ohnehin angepasst worden, wenn die registerattempts ausgeschöpft sind und das Monitoring alamiert wird irgendwann automatisch ein sip reload ausgelöst und das ganze nochmal von Vorne aufgerollt. Bei pascom 19 wäre das im übrigen wieder anders zu setzten.
. Nur was machen die Router Hersteller da besser als Asterisk?