SIP-ALG und Telekom


#1

Hallo in die Runde,

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 :wink:

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.

Gruß
Michael


#2

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.


#3

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.


#4

Hallo @crapp,

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.

Grüße,
Steve


#5

das hätte ich auch gerne :wink:


#6

Hi @Steve

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?


#7

Hallo @crapp,

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.

Grüße,
Steve


#8

Hallo Steve,

gibt es hierzu schon weitere Infos.


#9

Hallo,

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.

Grüße,
Steve


#10

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.

Grüße Malte


#11

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)
  • TCP Retransmission Problemen
    liegen.

Grüße,
Steve


#12

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.

TaskEngine.getInstance().scheduleAtFixedRate(script.timerTask, 2 * 60 * 1000, 4 * 60 * 1000)

Sehe ich das richtig das der Timer 2min verzögert alle 4min ausgeführt wird?

Das Script prüft aber ja noch mehr, und ich bin mir nicht sicher ob der Fall bei mir genau so ist, da ich ja einen Fehler bekomme.