- Mitglied seit
- 20 Jul 2015
- Beiträge
- 468
- Punkte für Reaktionen
- 53
- Punkte
- 28
Hallo,
ich habe vor Weihnachten eine IP-Umstellung bei einem Kunden mit einer be.IP 4isdn vorgenommen. Das hat auch ohne weiteres geklappt. Zwischen den Feiertagen kam eine Meldung rein, dass die Telefone zwar klingeln, es aber keine Audioübertragung gab. Die Firmware der be.IP 4isdn ist auf dem Stand von vor Weihnachten, also 10.1.27.105.
Bei der Überprüfung der be.IP 4isdn ist mir gleich aufgefallen, dass einer der DSP-Kanäle des integrierten 8DSP-V2-Moduls als belegt gekennzeichnet war, obwohl gerade keine Telefonverbindung aufgebaut war.
Nach einem Reboot der be.IP 4isdn war alles wieder einwandfrei.
Anfang Dezember hatte ich einen ähnlichen Fall bei einer be.IP plus im PBX-Modus an einem IP-Anschluss. Intern ist ein ISDN-Systel (CS400xt) als Zentralentelefon angeschlossen. Neben einem analogen Faxgerät gibt es dort auch noch zwei C430 via IP (GO-Box).
Beim CS400xt hat es bei eingehenden Anrufen zwar geklingelt, allerdings fand in keiner Richtung eine Audioübertragung statt. Das Telefonieren über die C430 war problemlos möglich.
Auch hier stellte ich fest, dass ein DSP-Kanal permanent belegt war. Im Klartext heißt das, dass in dem Zustand mit permanent belegtem DSP-Kanal (so zumindest gibt es die WebGUI dern Anlage an) kein Telefonieren mit einem klassischen Endgerät möglich ist.
Nach einem Reboot war auch hier alles wieder in Butter.
Genau dieses Phänomen war an der gleichen Anlage bereits im vergangenen Juni - damals noch mit einem älteren Firmwarestand - aufgetreten.
In der Vergangenheit hatte ich auch eine gleichlautende Meldung von einem Kunden mit einer hybird 130j. Nur habe ich dort noch nicht den Zustand der DSP-Kanäle im Fehlerfall geprüft.
Auch dort half ein Reboot, das Problem (erst einmal) zu beseitigen. Da es dort aber öfter aufgetreten ist, habe ich einen wöchentlichen Reboot in der Anlage eingerichtet. Seit dem ist das Phänomen laut Kunde nur ein einziges Mal aufgetreten, was man aber selbstständig durch einen Reboot behoben hat. Wenn es nochmal auftritt, schaue ich mir vor dem Reboot die Anlage genauer an.
Bereits im Juni hatte ich wegen der be.IP plus bei bintec elmeg nachgehakt. Der Fehler war nicht bekannt. Man wollte ein SIA-File, was aufgrund des mittlerweile erfolgten Reboots nicht mehr aussagekräftig erstellbar war.
Dieses Mal mit der be.IP 4isdn habe ich das SIA-File VOR dem Reboot erstellt und mit einem neuen Ticket eingeschickt. Das Ticket wurde meinem "Lieblingssupporter" bei bintec elmeg zugewiesen, welcher nun neben dem SIA-File auch einen DEBUG Mitschnitt gefordert hat.
Da ich mit dem Reboot nicht warten kann, bis nach Tagen mal eine Reaktion auf eine Ticketeröffnung erfolgt, war der Zug natürlich abgefahren.
Auch kann ich bei Fragen des Supports, was denn vor dem Eintreten des Zustandes genau getan wurde, erst mal nur den Kopf schütteln. Der Kunde ruft (via Handy) an, wenn er feststellt, dass was nicht klappt. An der be.IP 4isdn hängt eine Anlage mit 10 Nebenstellen, wo jedem Teilnehmer immer bekannt ist, wer gerade was gemacht hat (Sarkasmus!). Aber Hauptsache mal bei völliger Ahnungslosigkeit eine Gegenfrage gestellt.
Da der Fehlerzustand aus jetziger Sicht nicht provozierbar ist und ich von dem speziellen Supporter noch kein vernünftiges Vorgehen zur Eingrenzung bzw. Identifikation eines Fehlers erlebt habe, gehe ich davon aus, dass hierzu (wieder mal) keine Lösung kommt.
Da ich den Störfall gesichert bei zwei Systemen - evtl. sogar drei - beobachten konnte, kann ich mir vorstellen, dass das auch sonstwo vorkommt.
Daher meine Frage in die Runde: Hat jemand diesen Störfall schon gehabt?
ich habe vor Weihnachten eine IP-Umstellung bei einem Kunden mit einer be.IP 4isdn vorgenommen. Das hat auch ohne weiteres geklappt. Zwischen den Feiertagen kam eine Meldung rein, dass die Telefone zwar klingeln, es aber keine Audioübertragung gab. Die Firmware der be.IP 4isdn ist auf dem Stand von vor Weihnachten, also 10.1.27.105.
Bei der Überprüfung der be.IP 4isdn ist mir gleich aufgefallen, dass einer der DSP-Kanäle des integrierten 8DSP-V2-Moduls als belegt gekennzeichnet war, obwohl gerade keine Telefonverbindung aufgebaut war.
Nach einem Reboot der be.IP 4isdn war alles wieder einwandfrei.
Anfang Dezember hatte ich einen ähnlichen Fall bei einer be.IP plus im PBX-Modus an einem IP-Anschluss. Intern ist ein ISDN-Systel (CS400xt) als Zentralentelefon angeschlossen. Neben einem analogen Faxgerät gibt es dort auch noch zwei C430 via IP (GO-Box).
Beim CS400xt hat es bei eingehenden Anrufen zwar geklingelt, allerdings fand in keiner Richtung eine Audioübertragung statt. Das Telefonieren über die C430 war problemlos möglich.
Auch hier stellte ich fest, dass ein DSP-Kanal permanent belegt war. Im Klartext heißt das, dass in dem Zustand mit permanent belegtem DSP-Kanal (so zumindest gibt es die WebGUI dern Anlage an) kein Telefonieren mit einem klassischen Endgerät möglich ist.
Nach einem Reboot war auch hier alles wieder in Butter.
Genau dieses Phänomen war an der gleichen Anlage bereits im vergangenen Juni - damals noch mit einem älteren Firmwarestand - aufgetreten.
In der Vergangenheit hatte ich auch eine gleichlautende Meldung von einem Kunden mit einer hybird 130j. Nur habe ich dort noch nicht den Zustand der DSP-Kanäle im Fehlerfall geprüft.
Auch dort half ein Reboot, das Problem (erst einmal) zu beseitigen. Da es dort aber öfter aufgetreten ist, habe ich einen wöchentlichen Reboot in der Anlage eingerichtet. Seit dem ist das Phänomen laut Kunde nur ein einziges Mal aufgetreten, was man aber selbstständig durch einen Reboot behoben hat. Wenn es nochmal auftritt, schaue ich mir vor dem Reboot die Anlage genauer an.
Bereits im Juni hatte ich wegen der be.IP plus bei bintec elmeg nachgehakt. Der Fehler war nicht bekannt. Man wollte ein SIA-File, was aufgrund des mittlerweile erfolgten Reboots nicht mehr aussagekräftig erstellbar war.
Dieses Mal mit der be.IP 4isdn habe ich das SIA-File VOR dem Reboot erstellt und mit einem neuen Ticket eingeschickt. Das Ticket wurde meinem "Lieblingssupporter" bei bintec elmeg zugewiesen, welcher nun neben dem SIA-File auch einen DEBUG Mitschnitt gefordert hat.
Da ich mit dem Reboot nicht warten kann, bis nach Tagen mal eine Reaktion auf eine Ticketeröffnung erfolgt, war der Zug natürlich abgefahren.
Auch kann ich bei Fragen des Supports, was denn vor dem Eintreten des Zustandes genau getan wurde, erst mal nur den Kopf schütteln. Der Kunde ruft (via Handy) an, wenn er feststellt, dass was nicht klappt. An der be.IP 4isdn hängt eine Anlage mit 10 Nebenstellen, wo jedem Teilnehmer immer bekannt ist, wer gerade was gemacht hat (Sarkasmus!). Aber Hauptsache mal bei völliger Ahnungslosigkeit eine Gegenfrage gestellt.
Da der Fehlerzustand aus jetziger Sicht nicht provozierbar ist und ich von dem speziellen Supporter noch kein vernünftiges Vorgehen zur Eingrenzung bzw. Identifikation eines Fehlers erlebt habe, gehe ich davon aus, dass hierzu (wieder mal) keine Lösung kommt.
Da ich den Störfall gesichert bei zwei Systemen - evtl. sogar drei - beobachten konnte, kann ich mir vorstellen, dass das auch sonstwo vorkommt.
Daher meine Frage in die Runde: Hat jemand diesen Störfall schon gehabt?