Ja, das würde ich sogar fast bevorzugen (zumindest empfehle ich das jedem, der einen Lancom von der Telekom benutzt 
)
Also heute Morgen gab es wohl wieder Probleme. Gespräche sind wohl einfach abgebrochen und danach hat man immer ein Besetztzeichen gehört.
In den Logs tauchen folgende Meldungen auf:
[Aug 7 10:02:19] WARNING[47541][C-000000aa] chan_sip.c: Received response: “Forbidden” from ‘"Empfang " sip:tel.t-online.de;tag=as6b78f916’
[Aug 7 10:02:28] WARNING[51970][C-000000ab] chan_sip.c: Received response: “Forbidden” from ‘"Empfang " sip:tel.t-online.de;tag=as24709fc2’
[Aug 7 10:02:37] WARNING[51970][C-000000ac] chan_sip.c: Received response: “Forbidden” from ‘"Empfang " sip:tel.t-online.de;tag=as6fa8f131’
[Aug 7 10:03:11] WARNING[52014][C-000000ad] chan_sip.c: Received response: “Forbidden” from ‘“Empfang” sip:tel.t-online.de;tag=as5e626531’
Die Nummer habe ich entfernt.
Woran könnte das liegen?
Hi,
hat der Anschluss eine feste IP? Falls nein und es (hoffentlich) ein Businessanschluss ist, würde ich diese aktivieren. Ansonsten wäre interessant, ob peer und SRV Record unterschiedlich sind, denn dann sollte eigentlich das Server Plugin Script einen sip reload ausführen, was das Problem wiederum beheben sollte. Prüfen kann man das folgendermaßen:
als root user:
1.den Befehl asterisk -rx 'sip show peers' | grep trunk eingeben, die IP des peers sollte nun ausgegeben werden
2. die Registrierung mit dem Befehl astersik -rx 'sip show registry' prüfen
3. den SRV Record prüfen, dazu
- den Befehl
dig _sip._tcp.tel.t-online.de SRV +shorteingeben. Hier ist die Zeile in der Links der niedrigste Wert steht relevant - den Befehl
nslookup servernameausführen, den Servername aus vorheriger Zeile beziehen, Beispieln-epp-100.edns.t-ipnet.de. Zurück sollte dann idealerweise die gleiche IP wie beim peer kommen
Grüße,
Steve
Ja der Anschluss hat eine feste IP und der nslookup gibt die gleiche IP wie beim peer zurück. Ich weiß jetzt halt nicht ob das auch der Fall war als die Probleme aufgetreten sind.
Was wurde den unternommen um die Probleme zu lösen?
Nichts es hat nach ca. 30min einfach wieder funktioniert. Wann wird denn das Server Plugin Script immer ausgeführt? Ist damit das neue Skript für den Telekom SIP-Trunk gemeint und funktioniert das überhaupt am Mehrgeräteanschluss?
Ich glaube alle 5 Minuten oder weniger. Ja das Script berücksichtigt auch den Mehrgeräte-Anschluss, auch wenn dieser bei weiten “wackliger” ist und die Telekom zum Betrieb mit einer IP Telefonanlage (die nicht von Ihnen stammt) nur den SIP Trunk empfielt soweit ich weiß.
Heute das selbe Spiel…
Anruf mitten im Gespräch unterbrochen worden und dann beim Rückruf ist der Anschluss nicht mehr erreichbar (besetzt).
Wieder mit der selben Meldung.
[Aug 8 08:47:58] WARNING[22917][C-000000cc] chan_sip.c: Received response: “Forbidden” from ‘"" sip:tel.t-online.de;tag=as6d8e0b1f’
[Aug 8 08:48:23] WARNING[22917][C-000000cd] chan_sip.c: Received response: “Forbidden” from ‘"" sip:tel.t-online.de;tag=as5e980888’
[Aug 8 08:50:01] WARNING[23094][C-000000ce] chan_sip.c: Received response: “Forbidden” from ‘"" sip:tel.t-online.de;tag=as6508dd8c’
Hi,
bitte wie oben Beschrieben zum Fehlerzeitpunkt bitte die IP des peers im Asterisk und SRV Record abfragen.
Aufgrund der CLI sieht man nur das die Telekom die ausgehenden Anrufe ablehnt, aus der Erfahrung heraus ist das dann der Fall, wenn wir bereits bei der neuen IP registeriert sind (die über den SRV Record übermittelt wurde) und das Peer durch den sip reload noch nicht nachgezogen wurde.
Grüße,
Steve
Der Fehler ist heute am Vormittag noch einmal aufgetreten. Ich konnte noch rechtzeitig die IPs überprüfen und sie waren unterschiedlich…
Hat man mit Sipgate Basic ähnliche Probleme?
Sipgate setzt sein Loadbalancing “VoIP” freundlicher um, hier habe ich noch keinen wechsel der IP erlebt, also nein, dieses Problem tritt bei Sipgate nicht auf, wobei ich hier eher Sipgate Trunking empfehlen würde.
Das Problem hat sich in deinem Fall nicht von alleine innerhalb von 5 Minuten erholt?
Ich habe exakt das gleiche Problem. Wir nutzen Version 17.17. In unregelmäßigen Abständen sind Telefonate nicht möglich. Sie sagt es sei registriert. Nach dem ausführen der Befehle von oben stellte ich fest, dass die IPs unterschiedlich sind. Leider heilt sich dieser Zustand nicht von selbst (auch nicht über Stunden). Nur ein Neustart von Pascom löst das Problem. Wird das Script überhaupt ausgeführt oder muss dazu etwas eingestellt werden?
Es wäre sehr schön hier eine Antwort zu bekommen. Da das Problem langsam überhand nimmt. Die Telekom wechselt ständig die IPs und Pascom bleibt auf der alten sitzen. Nur ein händiger Sie reload löst das Problem.
Wann und wie wird das Script gerufen? Hier passiert über Stunden nichts wenn ich nichts von Hand mache.
1 Like
Ich hatte Gestern auch das gleiche Verhalten. Erst nach einem manuellen “sip reload” über die cli hat es wieder funktioniert.
Mittlerweile kann man ja bei der Telekom eine Funktion aktivieren, sodass die Anrufe weitergeleitet werden wenn der Account nicht angemeldet ist. Aber die Anlage verliert bei dem IP-Wechsel nicht die Verbindung zum Server und somit greift die Weiterleitung auch nicht. Ein “sip show peers” oder “sip show registry” zeigt auch keine Unauffälligkeiten. Alle Peers sind online und registriert.
Ich verstehe auch nicht ganz wieso eine FritzBox oder ein Speedport mit dem IP-Wechsel keine Probleme hat aber die Pascom schon?
Eine (oberflächliche) Teilantwort hierzu lautet, dass die genannten Geräte ja direkt die Router sind, auf denen auch die Telefonie-Funktionen implementiert sind. Damit enfällt dann beispielsweise das Thema NAT.
Geräte, die hinter dem Router im internen Netzwerk angeschlossen sind, verfügen also immer über einen Eintrag in der NAT-Tabelle des Routers, damit der Router weiß, wohin ein externes Paket intern weitergeleitet werden muss. Ändert sich nun die externe IP, gibt es zwar u.U. in der NAT-Tabelle noch einen Eintrag dazu, der auch passend zur Pascom weitergeleitet wird. Allerdings passt in dem Moment die Quell-IP nicht mehr überein mit dem, was die Pascom davon kennt. In der Folge gibt es ein no-auth-in auf der Konsole zu sehen. Die Accounts werden alle als registriert angezeigt. Die derzeit unter der Haube genutzte Asterisk-Version spielt da auch eine Rolle. Die wird sich erst mit Pascom 18 ändern und dann wird hoffentlich alles gut.
Es kann auch sein, dass in der NAT-Tabelle keine passender Eintrag mehr vorhanden ist und das Paket ganz verworfen wird.
Wie erwähnt, ist alles oberflächlich und vereinfacht beschrieben, ohne zur sehr ins Detail zu gehen.
Hallo wenn das Problem bei dir so schlimm ist und sich das mit eine sip reload beheben läßt.
Dann wäre es ja auch möglich einen CronJob zum erstellen der z.B alle Stunde einen sip reload macht
Hallo,
Ja das habe ich auch genauso gemacht. Nur haben wir so im schlimmsten Fall 1h kein Telefon gehabt. Dieses “tolle” Script welches das von selbst beheben soll alle 5 Minuten macht überhaupt nichts. Muss dieses irgendwie aktiviert werden?
Hi meine das automatisch aktiv.
Hast du eine Kauflizenz? Dann rufe bei Support an oder melde dich bei deinem Dienstleister das die Pascom installiert hat.
Ich habe inzwischen einige Kunden die den Trunk von der Telekom haben und bei denen funktioniert das Script ohne Probleme.
Gruß Markus
Bei mir bestehen genau die gleichen Symptome, auch nach einem Cronjob der ein SIP reload ausführt kommt es im schlimmsten Fall dazu dass das Telefon über längeren Zeitraum nicht funktioniert.
Es wäre schön wenn das Script hierzu vielleicht auch einmal veröffentlicht werden würde.
Das Skript ist auch keine Allzweckwaffe sondern behebt nur den Umstand, dass die Telekom bei der Namensauflösung auf eine andere IP-Adresse verweist als die, bei der sich die TK zuletzt registriert hat und führt dann einen SIP-Reload aus.
Bei einem Ausfall von einer Stunde liegt jedoch eher der Verdacht nahe, dass die von euch verwendeten Nameserver noch nichts davon mitbekommen haben, dass sich die IP seitens der Telekom geändert hat. In dem Fall gibt es für das Pascom-Skript nichts zu tun.
Daher wäre u.a. zu prüfen, welchen Nameserver ihr in der Pascom eingetragen habt (am besten den vom Router, der sich dann die DNS-Adressen dynamsich vom Telekom-Server holt - sprich im Router kein DNS-Cache aktivieren).
Weiterhin ist spannend zu erfahren, ob ein Router-Neustart in dem Fall schneller zu einer Verfügbarkeit führen würde.
Die Telekom und deren Loadbalancing über DNS ist eine echte Herausforderung 
Ansonsten schließe mich mich @MarkusSachs an. Pascom-Support ansprechen bzw. den Fachhändler vor Ort.
Gruß
Michael