Gelöst
Digitalisierungsbox Premium - Telefonieprobleme
vor 10 Jahren
Firmware V.10.1 Rev. 3 (Patch 19) PBX
Seit ich gestern 22.00 auf Patch19 aktualisiert habe, lassen sich einzelne Nummern wechselnd nicht registrieren.
Ich habe es jetzt noch nicht im Detail nachvollzogen, weil ich heute erst am späten Nachmittag Zeit dafür habe. Jedoch fallen die Registrierungsprobleme mit dem Update zusammen. Betroffen Telekom-Nummern, Sipgate und auch voip2gsm.
Sofern keine Großstörung vorliegt (hab ich auch noch nicht recherchiert) werde ich ggf. heute abend wieder auf Patch 12 downgraden, sofern die Anlage mir das erlaubt. Ich hatte vorsichtshalber vor der Aktualisierung nachgesehen, ob ich entsprechende Datei im Dowwnloadordner habe .
2730
0
59
Das könnte Sie auch interessieren
Kaufberatung
Sie benötigen eine persönliche Kaufberatung? Das Geschäftskundenteam der Telekom berät Sie gerne.
Angebote anzeigen
Informieren Sie sich über unsere aktuellen Internet-Angebote.
vor 10 Jahren
Hallo,
ich habe Sipgate, NoNoh und Megavoip, keine Probleme mit P119.
Empfehlung: Diese Konten mit dem Wizard und der Option Assistent --> Telefonie --> Anschlüsse --> Neu --> Sip-Provider --> Benutzerdifiniert neu anlegen.
Bei Sipgate hat sich (vermutlich) zum Jahreswechsel was geändert. In der Requstline muss jetzt die Auth-ID stehen, damit der eingehende Ruf verarbeitet werden kann und bei abgehenden Telefonaten im Header ebenfalls....ich musste das umstellen, über den Wizard und den oben beschriebenen Weg.
0
57
von
vor 10 Jahren
Die oben zitierte Antwort ist alles was ich habe und ich könnte mir vorstellen, das das Problem bei der be.ip genauso zugeschlagen hätte, weil man es schlicht nicht auf dem Schirm hatte. Warum sich das fällige Update der be.ip verzögert weiß mglw. @Kalle2014 oder @NPS011172.
Daraus könnte man dann mglw. auch ableiten wie es mit der Digitalisierungsbox weitergeht. Eigentlich ist das in diesem Thread aber OT
Ich würde dessen ungeachtet gern erfahren, warum @wirsinds so sehnsüchtig auf eine neue FW wartet. Die von Ihm zuletzt eröffneten Threads geben darauf für mich keinen Hinweis.
von
vor 10 Jahren
Nach meiner Info hat de be.IP (ich finde, das passt hier sehr gut rein, weil sie im Gund baugleich sind) den Patch 19 nicht bekommen, weswegen das Problem dort nicht auftaucht.
Ich konnte mir jetzt mit dem Workaround helfen, so dass ich nun nach Monaten endlich wieder über das VPN Nebenstellen registrieren und verwenden kann. Aber dem liegt ja ein Fehler/Problem in der Firmware zugrunde, und den hätte ich gerne wieder gefixt und die Rückroutenprüfung eingeschaltet.
Daher ist es jetzt dank deiner Rückmeldung wieder funktional und nicht mehr so dringend - ich frage mich aber, wieso das bei einem bekannten Problem und einer klaren Ansage "wenige Wochen" so lange dauern kann, dass dieses Problem gefixt wird?
0
von
vor 10 Jahren
Nach meiner Info hat de be.IP (ich finde, das passt hier sehr gut rein, weil sie im Gund baugleich sind) den Patch 19 nicht bekommen, weswegen das Problem dort nicht auftaucht.
Nach meiner Info hat de be.IP (ich finde, das passt hier sehr gut rein, weil sie im Gund baugleich sind) den Patch 19 nicht bekommen, weswegen das Problem dort nicht auftaucht.
Das ist richtig und hatte ich oben auch erwähnt.
Ich konnte mir jetzt mit dem Workaround helfen, so dass ich nun nach Monaten endlich wieder über das VPN Nebenstellen registrieren und verwenden kann. Aber dem liegt ja ein Fehler/Problem in der Firmware zugrunde, und den hätte ich gerne wieder gefixt und die Rückroutenprüfung eingeschaltet. Daher ist es jetzt dank deiner Rückmeldung wieder funktional und nicht mehr so dringend - ich frage mich aber, wieso das bei einem bekannten Problem und einer klaren Ansage "wenige Wochen" so lange dauern kann, dass dieses Problem gefixt wird?
Ich konnte mir jetzt mit dem Workaround helfen, so dass ich nun nach Monaten endlich wieder über das VPN Nebenstellen registrieren und verwenden kann. Aber dem liegt ja ein Fehler/Problem in der Firmware zugrunde, und den hätte ich gerne wieder gefixt und die Rückroutenprüfung eingeschaltet.
Daher ist es jetzt dank deiner Rückmeldung wieder funktional und nicht mehr so dringend - ich frage mich aber, wieso das bei einem bekannten Problem und einer klaren Ansage "wenige Wochen" so lange dauern kann, dass dieses Problem gefixt wird?
Es freut mich, das es geholfen hat. Deswegen hab ich die Antwort auch gepostet. Ich war schon am verzeifeln, weil ich anscheinend wieder mal allein war
Ich vermute, daran wird gearbeitet. Aber wie das so ist mit "organisch" gewachsenen Softwaremodulen - da muß genauestens auf Querverknüpfungen getestet werden. Die letzte Prüfung war offensichtlich lückenhaft, weswegen das überhaupt passiert ist.
Ich möchte auch darauf hinweisen, das ich vor P19 schon die Standorte für alle SIP-Anschlüsse aktiviert hatte - und mit P19, wo dieses Feature eigentlich erst funktionabel sein sollte hat da garnix mehr funktioniert, sodass ich das bis auf weiteres erstmal außen vor lasse.
Edit: Ich komme aus dem Bereich Industrieautomation. Fatale Auswirkungen kleinster Änderungen sind mir aus eigener leidvoller Erfahrung bekannt, weswegen ich auch ein gewisses Verständnis dafür aufbringe. Wobei bintec deutlich mehr Ressourcen hat als ich
0
Uneingeloggter Nutzer
von
Akzeptierte Lösung
akzeptiert von
vor 10 Jahren
Falls es noch jemanden interessiert, die Antwort der Experten kam gerade eben:
Wie gewünscht, informiere ich Sie hiermit über die Fehlerursache Ihrer Digitalisierungsbox mit Patch 19. „Bitte schalten Sie unter Netzwerk > Routen > Optionen > Überprüfung der Rückroute = "nicht aktiv" für alle Interfaces. Damit sollte das Verhalten nicht mehr auftreten. Das Problem trat mit lokal erzeugten Paketen auf, die ohne Absenderadresse in das Backrouteverify gelaufen sind. Da dieses jedoch auch nach Absenderadresse arbeitet, wurden die Pakete geblockt. Für dieses Verhalten haben wir eine Lösung entwickelt, die in den Patch 20 mit einfließt.“ „Bitte schalten Sie unter Netzwerk > Routen > Optionen > Überprüfung der Rückroute = "nicht aktiv" für alle Interfaces. Damit sollte das Verhalten nicht mehr auftreten. Das Problem trat mit lokal erzeugten Paketen auf, die ohne Absenderadresse in das Backrouteverify gelaufen sind. Da dieses jedoch auch nach Absenderadresse arbeitet, wurden die Pakete geblockt. Für dieses Verhalten haben wir eine Lösung entwickelt, die in den Patch 20 mit einfließt.“ „Bitte schalten Sie unter Netzwerk > Routen > Optionen > Überprüfung der Rückroute = "nicht aktiv" für alle Interfaces. Damit sollte das Verhalten nicht mehr auftreten. Das Problem trat mit lokal erzeugten Paketen auf, die ohne Absenderadresse in das Backrouteverify gelaufen sind. Da dieses jedoch auch nach Absenderadresse arbeitet, wurden die Pakete geblockt. Für dieses Verhalten haben wir eine Lösung entwickelt, die in den Patch 20 mit einfließt.“
Wie gewünscht, informiere ich Sie hiermit über die Fehlerursache Ihrer Digitalisierungsbox mit Patch 19.
„Bitte schalten Sie unter Netzwerk > Routen > Optionen > Überprüfung der Rückroute = "nicht aktiv" für alle Interfaces. Damit sollte das Verhalten nicht mehr auftreten. Das Problem trat mit lokal erzeugten Paketen auf, die ohne Absenderadresse in das Backrouteverify gelaufen sind. Da dieses jedoch auch nach Absenderadresse arbeitet, wurden die Pakete geblockt. Für dieses Verhalten haben wir eine Lösung entwickelt, die in den Patch 20 mit einfließt.“
„Bitte schalten Sie unter Netzwerk > Routen > Optionen > Überprüfung der Rückroute = "nicht aktiv" für alle Interfaces. Damit sollte das Verhalten nicht mehr auftreten.
Das Problem trat mit lokal erzeugten Paketen auf, die ohne Absenderadresse in das Backrouteverify gelaufen sind. Da dieses jedoch auch nach Absenderadresse arbeitet, wurden die Pakete geblockt.
Für dieses Verhalten haben wir eine Lösung entwickelt, die in den Patch 20 mit einfließt.“
0
Uneingeloggter Nutzer
von