Die Appliance verliert, in unregelmäßigen Abständen zischen 4 und 7 Tagen, die SIP-Verbindung zum Provider. Zwar kann die Verbindung durch einfaches sip reload in der cli wieder hergestellt werden, aber der Grund des Verbindungsverlustet ist unersichtlich. Die Verkürzung der Anmeldezeit auf 300 Sek. war ein Ansatz, hat aber auch nicht zum Erfolg geführt.
Hallo der_boedi,
um welchen Provider und Produkt handelt es sich denn?
Ich habe zum Beispiel gleiche Probleme mit einem Telekom Deutschland LAN IP Voice/Data Premium Tarif. Seit 01.04. sind die Tage eher selten an denen der Registrierungsversuch der Nummern nicht mindest einmal täglich in den Timeout läuft und ein neuladen (sip reload o.ä.) notwendig macht.
Ich hatte auf Hinweis des Supports das Amt unter aktueller Pascom-Version (18.06) einmal neu angelegt, wodurch neben den aktuellen Einstellungen auch ein sog. ServerPlugin-Script zum Einsatz kommt. Dadurch haben sich die Ausfälle bereits etwas minimiert.
Ausserdem hat es geholfen den Schlüssel ‘registerattempts’ unter sys>asterisk>configure>sip zu erstellen und somit den Standard-Wert von 20 Registrierungsversuchen anpassen zu können - in meinem Fall fahre ich aktuell mit 39 ganz gut, das sind dann 13 Minuten bis der Timeout kommt und die Benachrichtigung rausgeht.
Vielleicht hilft dir das auch schon mal weiter.
Grüße
Gabs die Probleme bei der vorherigen Version auch?
Hatte selber mal solch ähnliche Probleme, zwar mit einer anderen Anlage aber auch Asterisk.
Fehler war bei mir der Mikrotik bzw die Connections. Wenn das Internet für nur wenige ausgefallen ist( hat keiner bemerkt) brauchte der Mikrotik ewig bis er das raffte und die Connections neu aufbaute.
Vllt ist es es so etwas ähnliches bei euch auch…
Hallo SteveR
es handelt sich beim Provider um die DTS (Deutsche Telefon Standart), mit der alle anderen, von uns errichteten, Anlagen sehr sauber laufen.
Deinen anderen Hinweisen gehe ich nach.
Vielen Dank dafür!!!
Hallo Christian
Die Anlage ist neu beim Kunden, daher keine Vorgängerversion.
Danke für den Tip!!!
Achso was wir machten, falls jemand Interressiert…
Bei der Firewall unter Connections haben wir beim Tracking auf “YES” gestellt und die Zeiten angepasst.
Hallo zusammen,
ich hatte das selbe Problem auch schon mit Peoplefone Trunk Anschlüssen.
Mit den Telekom Deutschland LAN IP Trunk Anschlüssen habe ich selbe Erfahrung auch schon zweimal gemacht.
Wenn sowas auftaucht mache ich einen sip reload
Grüße
Die Fritzbox hat ja anscheinend einen Timeout um DoS-Attacken zu verhindern.
Wieso diese die Anmeldung der pascom ablehnt, kann man an der Box schlecht diagnostizieren.
Sip Reload hilft natürlich, aber das ist für den Kunden ja nicht zufriedenstellend, wenn er alle paar Tage beim Support anrufen muss. Ich hatte schon überlegt, mit einem Cronjob 1x am Tag den SIP_reload manuell anzustoßen, aber da der Wert qualifyfreq auf 600 steht, kann es ja jederzeit am Tag passieren, dass die Fritzbox die Anmeldung ablehnt.
Und täglich grüßt der ‘sip reload’…
In meinem Fall und ich denke auch in @der_boedi ´s Fall werden die Telekomnummern ja direkt an den Telekom-Servern über ein Amt in der PAscom registriert, die FritzBox hat hiermit nix zu tun, trotzdem danke für die Mithilfe.
Als Ausfalllösung habe ich mittlerweile ein Sipgate-Amt angelegt und im Telefoncenter der Telekom diese Nummer bei der Offline-Weiterleitung hinterlegt, somit sind eingehende Gespräche zumindest sichergestellt.
@Christian am Mikrotik kanns übrigens auch nicht liegen, den verwenden wir hier nicht.
Das Problem trat das erste Mal am 01.04. zwischen 2 und 3 Uhr morgens auf, also genau im Wartungsfenster der Telekom und die Anlage lief vorher 2 Monate (nach Upgrade auf V18) ohne Unterbrechungen, ich gehe also stark von einer Änderung seitens der Telekom aus. Der T-Support kann/will dazu nichts sagen. Änderungen an Netzwerkkomponenten unsererseits gab es in diesem Zeitraum nicht…
@der_boedi, meintest du mit “Verkürzung der Anmeldezeit…” den Wert registertimeout in den Account-Optionen des Amts?
Nachdem ich, wie bereits erwähnt ein sipgate-trunk als Backup eingerichtet hatte, ist mir dieser Wert nämlich in den Optionen aufgefallen. Da der trunk von Anfang an stabil lief, habe ich ‘registertimeout=600’ einfach mal in den Optionen des Telekom-Amts eingefügt und siehe da seitdem gab es keine Registrierungsausfälle mehr (aktuell seit 5 Tagen). Scheint als könnte das die/eine Lösung sein, zumindest in meinem Fall.
Nachtrag: ‘registertimeout=600’ in den Optionen des Telekom-Amts hat das Problem leider doch nicht beseitigen können, das Intervall für Registrierungsversuche blieb unverändert bei 20 Sekunden. Mit folgenden Einstellungen ist nun jedoch schon seit 27.05. (~2 Wochen) Ruhe und es gab keinen Ausfall mehr:
sys.asterisk.configure.sip.file.registertimeout = 66 (Sekunden zwischen den einzelnen Registrierungsversuchen, Standard ist 20)
sys.asterisk.configure.sip.file.registerattempts = 10 (Anzahl der Registrierungsversuche bis Timeout und E-Mail-/icinga-Benachrichtigung, Standard ist 20)
Grüße
Hallo,
wir haben seit der Inbetriebnahme der Pascom Anfang dieses Jahres an einem Telekom ALL IP die selben Probleme. Laut Telekom Log hört die Pascom ab Zeitpunkt X einfach auf sich bei der Telekom zu melden. Es kommt bei der Telekom nichts mehr an. Es geht manchmal einen Monat gut, dann schmiert der Eimer täglich ab. Ob das besagte Script seinen dienst verrichtet…
Das Thema dnsmgr.conf
das habe ich noch gefunden, aber nicht weiter ausprobiert… sonst gibt es einige Threads wo das Thema hier behandelt wird aber ohne Finale Lösung. Wir haben einen Easybell Anschluss der noch nie ein Problem gemacht hat, mal schauen ob wir die Nummern umziehen oder die Pascom ablösen. Das ist so kein zustand.
Hallo,
mit der Telekom kämpfen wir aktuell auch bei 2 Kunden mit den selben Problemen. Eine Anlage ist erst 1 Woche alt und die Probleme treten aktuell im Tagesrhythmus auf.
Eine Lösung haben wir auch noch nicht gefunden.
Gruss
Flo
Hi, ich hab hier nochmal das wichtigste zu den Telekom SIP Ämtern (OnSite) zusammengefasst, bitte mal einen Blick darüber werfen:
In der pascom.cloud ist das Templete ausreichend, lediglich das qualify könnte man hier deaktivieren um uns das Leben leichter zu machen.
Grüße,
Steve
Ich habe ein Pascom.cloud und auch wir verlieren seit etwa 2 Wochen regelmäßig die Verbindung zum SIP-Trunk. 2 von 3 Providern sagten mir, dass die Verbindung der Leitung sehr stark schwankt. Gestern habe ich 2x die Verbindung verloren. 1x für 1 Minute und einmal für 8 Minuten. Insgesamt passiert es nun fast 10x in diesen 2 Wochen. Wobei sich diese 10x auf 3-4 Tage verteilen. An den meisten Tagen ist alles in Ordnung. Es scheint jedenfalls etwas nicht zu stimmen.
Hi,
verliert den wirklich der SIP Trunk die Verbindung (denn das hätten wir weder beim alten noch beim neuen Telekom Proxy in der pascom.cloud beobachtet, außer in den Fällen in denen der Anschlussgehörige Router ebenfalls mit den SIP Zugangsdaten einwählt) oder die Benutzer die Verbindung zur pascom.cloud?
Sollte die Appliance Support haben kannst du dich ja dort mal melden.
Bezüglich des “kein Ton bei eingehenden Gesprächen” Problems ist es wichtig den aktuellen Proxy zu verwenden und nicht den alten mit de1out50. Für den neuen einfach die Telekom Vorlage verwenden oder das bestehende Amt bezüglich
Host: reg.sip-trunk.telekom.de
und Optionen:transport=tcp (hinzufügen, rest wie gehabt) anpassen.
Grüße,
Steve
Hallo Steve
bei mir ist es nicht die Telekom, sondern Deutsche Telefon, IP Austria und AstraQom und alle verlieren seit rund 2 Wochen hin und wieder die Verbindung, allerdings immer zeitgleich.
LG
Da ist mal wieder so ein Klassiker
Und täglich grüßt der ‘sip reload’…
Ein Paar nummern sind drin, einige nicht und sip reload fixt das ganze
Hallo zusammen,
leider sind die hier geschilderten Probleme für uns etwas undurchsichtig da pascom.cloud, Onsite und diverse Provider vermischt werden die evtl. jeweils andere Ursachen haben.
Ich würde alle die noch Probleme haben bitten Folgendes zu machen:
Unter Appliance > Systemeinstellungen im Pfad sys.asterisk.configure.sip.file den Parameter registerattempts mit dem Wert 0 anlegen.
Danach Anwenden > Telefonie (unterbricht die laufenden Gespräche nicht).
Hintergrund
Wir setzen diesen Wert defaultmäßig auf 20 da sich der Asterisk bei z.B. fehlerhaften Daten immer wieder registriert und manche Provider als Resultat den Trunk oder unsere Cloud-IPs ganz sperren.
Bei Providern mit Loadbalancern kann es sein, dass durchaus mal 20 reg-versuche ins Leere laufen (Schwenk, etc) oder onsite eine Internetverbindung neu aufgebaut wird, dann würde das Amt, wie bei @the_muck auf “Failed” stehen bleiben.
Ein Reload setzt den Zähler zurück und es geht wieder.
LG
Mathias
Hallo Mathias,
da eine E-Mail-Benachrichtigung ja erst nach dem Ablauf der ‘registerattempts’ gesendet wird, habe ich bisher absichtlich vermieden den ‘registerattempts’ wert auf 0 zusetzen, da ich bei einem Ausfall der Leitungen als Zuständiger möglichst als erstes informiert werden möchte und nicht von Mitarbeitern/Kunden erst darauf aufmerksam gemacht werden will das etwas nicht stimmt. Eine annehmbare Benachrichtigungs-Zeit wäre m.M.n. z.B. 10 bis 15 Minuten. Es muss also zumindest bereits während der laufenden Registrierungsversuche eine Benachrichtigung möglich sein!
Btw waren die Tkom-Leitungen hier gerade seit ca. 18 Uhr mal wieder unregistriert, nachdem es fast 3 Wochen ohne Ausfälle lief… auch ein manueller reload behob das Problem bis ca 23 Uhr nicht
Vielleicht hilft mal ein Vergleich der Konfigurationen bzw. erstellt ihr mal eine Vorlage welche Informationen von Nutzen sein könnten
Konfiguration:
- Pascom 18.07 (VM)
- Vorlage “Telekom” Version 18.04
- Telekom Deutschland LAN IP Voice/Data Premium, Registrierung je Nummer, feste IP
- Pascom-DNS = Telekom-DNS
- Firewall: ipfire, kein SIP-ALG
- Router: FritzBox 3490
- Optionen:
– nat=force_rport,comedia
– fromuser=XXX
– fromdomain=tel.t-online.de
– insecure=invite
– videosupport=no
– disallow=all
– allow=alaw
– qualify=yes
– directmedia=no
– session-timers=refuse
– transport=tcp
– registertimeout=600 - sys.asterisk.configure.sip.file>‘registerattempts’=10
- sys.asterisk.configure.sip.file>‘registertimeout’=66
die Option ‘qualifyfreq=270’ habe ich soeben erst noch hinzugefügt, wie hier beschrieben SIP-ALG und Telekom und werde wieder berichten…
Gruß,
Steve