Posts by Daniel Mauritz

    Zunächst einmal vielen Dank euch allen für die hilfreichen Hinweise, die zahlreichen Hilfestellungen zum Modul "Provision Toolbox" und den korrekten Provisionierungseinstellungen!

    Wir haben im eigenen Unternehmen nur T54W, alle auf dem gleichen Firmware-Stand (96.86.150.5).


    Die funktionierenden Geräte stehen auf "Sommerzeit: automatisch" und erhalten die korrekte Einstellung mit "letzter Sonntag im März".

    Die nicht funktionierenden Geräte stehen auch auf "Sommerzeit: automatisch", erhalten aber die falsche Einstellung "vierter Sonntag im März"


    Ich vermute, es liegt am Autoprov einer der neueren Starface-Versionen: wenn wir ein funktionierendes Telefon komplett zurücksetzen und "jungfräulich" auf die Starface loslassen, erhält es danach die "falschen Einstellungen" - gerade eben getestet.

    Die Geräte mit korrekter Uhrzeit sind hauptsächlich die Geräte von Kollegen, die schon länger im Unternehmen sind - die falschen die von neueren Kollegen ;)

    Danke auch für diesen Hinweis...

    Aber man könnte es prüfen (fehlt) mir grad die Zeit - aber könnte STARFACE ja machen ;)

    ... und genau das werden wir auch tun. Es sollte natürlich schon so sein, dass die richtigen Einstellungen provisioniert werden.

    Wir geben das natürlich weiter an die Entwicklung, damit allgemeingültigere Einstellungen provisioniert werden, die auch solche Ausnahmen wie in diesem Jahr abdecken.

    Hallo,

    wir können bestätigen dass es aktuell ein Problem mit der Uhrzeitanzeige auf verschiedenen Yealink-Telefonen gibt. Wir erhalten auch schon etliche Tickets zu dem PRoblem. Die Geräte scheinen schon die Sommerzeit anzuzeigen. Die Kollegen sammeln derzeit die erforderlichen Informationen ein, damit unsere Entwicklung das Verhalten prüfen kann.

    Für einen Überblick würde es uns helfen, wenn Ihr hier die Modellbezeichnungen, Firmwareversion und Anlagenversion posten könntet, denn es scheint nicht alle Modellreihen zu betreffen.

    Danke!

    Den Banner entferne ich noch. Zur Klarstellung: Wir hatten zwei verschiedene Themen, die aufgrund des großen Trubels heute vormittag hier im Thread vermischt wurden.

    1. Ein Fehler in der API hat gestern abend zur initialen Meldung geführt, weshalb das Cloudmanagement in den Wartungsmodus versetzt wurde.

    2. Dann kam der heutige Ausfall unserer internen Systeme dazu, was hier im Thread ergänzt wurde.

    Nachdem die internen Systemen wieder verfügbar waren, wurde auch das Cloudmanagement wieder freigeschaltet, obwohl wir noch kein Feedback von den Kollegen erhalten haben.

    Update 07.03.2024, 15:45 Uhr: Der API Fehler ist auch als behoben bestätigt worden, das Cloudmanagement ist wieder freigegeben.

    Die internen Systeme fahren langsam wieder hoch, es kann allerdings noch ein wenig dauern bis alle wieder online sind.

    Es handelte sich nicht um eine Störung bei Netcup, sondern um einen Fehler in unseren eigenen Systemen. Leider gibt es da auch gewisse Abhängigkeiten zu unseren Anlagen, z. B. durch den Lizenzserver, siptrunk.de oder das Partner-Portal.

    Dvon waren wir intern genau so betroffen: Es war praktisch alles offline, außer der Internetzugang über das Gast-WLAN. So konnten wir zum Beispiel über eine Cloud-Anlage die Telefonie temporär, wenn auch eingeschränkt, wiederherstellen.

    Wir prüfen sehr genau was da passiert ist und werden anschließend Maßnahmen einleiten, um Fehler dieser Art zukünftig auszuschließen und Redundanzen zu schaffen wo nötig.

    Hallo Scaramu

    eine solche bzw. ähnliche Übersicht hast du doch, wenn du dir die Beiträge in der jeweiligen Kategorie der Known-Issues anschaust. In letzter Zeit werden die auch mit Tags für zusätzliche Informationen versehen:

    STARFACE PBX

    Wenn man dann noch Detail-Informationen braucht, kann man sich den ersten Beitrag oder den gesamten Thread anschauen. Damit ist dein Vorschlag im letzten Beitrag doch bereits erfüllt, wenn auch rein optisch in etwas anderer Form.

    Und da es auch in diesem Thread verschiedenste Vorschläge und Anforderungen gibt, von einfachen Übersichten (wie zuletzt) bis hin zu vollständigen Listen (wie zuvor in der Diskussion), abschließend nochmal der Hinweis: Vollständige Listen können und werden wir nicht veröffntlichen, die Known-Issues sind bereits in Listenform mit Zusatztags einsehbar und wir werden intern prüfen ob wir noch ein wenig offener werden können was deren Umfang angeht.

    Hallo zusammen,

    ich verfolge die Diskussion hier schon seit ein paar Tagen und möchte gerne auf einige Punkte davon eingehen.

    Zunächst einmal gibt es den Known-Issues Bereich hier im Forum, um euch über die aus unserer Sicht wichtigen und gravierenden bekannten Probleme zu informieren. Hierbei handelt es sich um eine kuratierte Liste, über deren Inhalte im Übergabeprozess von Support in Richtung PM / Development entschieden wird.

    In diesem Prozess werden aus Support-Tickets Jira-Tasks erstellt, die zunächst von der QA nochmal geprüft und anschließend zur Einplanung an das PM / Development übergeben werden. Bei der Erfassung aller erforderlicher Informationen im Jira-Task werden die Infos aus einem oder mehreren Tickets zusammengeführt und Titel und Zusammenfassung / Beschreibung so formuliert, dass das Development möglichst genau weiß um welchen Fehler es sich handelt. Daraus ergibt sich oft genug eine Beschreibung, die auf den ersten Blick nicht mehr viel gemeinsam hat mit der Beschreibung, die unsere Partner uns senden.

    Ich verstehe den Wunsch nach einer vollständigen Liste, aber wie hier im Thread schon erläutert wurde, können wir eine solche Liste nicht veröffentlichen:

    1. Für Personen, die Prozesse und auch Fehler in der Softwareentwicklung kennen, wäre der Umfang vermutlich nicht überraschend da sie viele "Kleinigkeiten" enthält. Und natürlich gibt es in einer solchen Liste auch vieles, was nur in ganz bestimmten Situationen zu einem Fehler oder ungewollten Verhalten führt. Andere Personen, die damit nicht vertraut sind, würde eine solch umfangreiche Liste aber eher abschrecken.

    2. Dazu kommt, dass ein großer Teil der Liste keine oder nur sehr ungenaue Rückschlüsse auf das Verhalten der PBX in einer ganz bestimmten Situation (Version A mit Provider B, Endgeräten C+D und Konfiguration E) zulässt. Der Hintergrund ist, wie oben beschrieben, die Überführung von Ticket-Informationen in Jira-Tasks. Unsere Partner beschreiben so gut wie immer die Symptome, aber nicht die (vermuteten) Ursachen.

    3. Daneben gibt es noch Datenschutzgründe, die gegen eine Veröffentlichung einer vollständigen Liste sprechen. Bei der Vielzahl an Tasks kann es immer sein, dass personenbezogene Daten im Titel eines Tasks stehen, die für die Identifikation des Fehlers z. B. in Logs und Dumps für das Development erforderlich sind. Diese dürfen nur zum Zweck der Bearbeitung erhoben und gespeichert werden. Wir können natürlich nicht zulassen, dass solche Informationen versehentlich veröffentlicht werden.

    Aus diesen Gründen können und werden wir keine vollständige Liste veröffentlichen.

    Ich weiß, dass ich auf dem Kongress und bei anderen Gelegenheiten schon häufiger über ein neues Ticketsystem gesprochen habe. Das wird auch kommen, aber in den vergangenen Monaten und Jahren gab es andere Prioritäten. Hierzu gehörte insbesondere die Reduktion offener Tickets und Verbesserung der Reaktionszeiten, zwei Bereiche, in denen wir große Fortschritte gemacht haben und in denen wir uns auch weiter verbessern wollen.

    In einem neuen Ticket-System stelle ich mir auch eine Verknüpfung eines Tickets zu einem Jira-Task vor, so dass zumindest dessen Nummer, der Status und ggf. die Zielversion transparent angezeigt werden. Schon jetzt verknüpft der Support neue Tickets mit ggf. bereits bestehenden Jira-Tasks. Somit bekäme jeder Partner in einem Ticket die Information angezeigt.

    Da auch das Partner-Portal hier erwähnt wurde, noch ein paar Worte zu Abgrenzung der verschiedenen Portale / Systeme:

    Forum

    Meine Mitarbeitenden aus den Support-Teams bzw. der Customer Care Abteilung engagieren sich schon jetzt im Forum. Das Forum hat seit der Überarbeitung auch einige offizielle Bereiche (Wartungen, Fehlerfälle, Releases, Betas, Known-Issues) dazu erhalten, weil es sich als Kommunikationsplattforum sehr gut für solche Zwecke eignet.

    Das Forum ist für uns auch weiterhin ein sehr wichtiger Baustein zur Kommunikation mit der Community und als Plattform für den gegenseitigen Wissensaustausch. Die Community-Bereiche werden wir aber auch zukünftig unter dem Motto "Partner helfen Partnern" oder auch "Power-User helfen Power-Usern" führen. Daher erfolgt das Engagement des Supports auch weiterhin eher "nebenbei" neben der Bearbeitung von Support-Tickets.

    Partner-Portal

    Das Partner-Portal dient offiziellen Veröffentlichen die für unsere Partner bestimmt sind sowie der Verwaltung und Bestellung. Natürlich gibt es da auch inhaltliche Überschneidungen, aber wir prüfen immer ob Informationen nur für Partner bestimmt sind oder ob wir sie auch öffentlich im Forum kommunizieren können.

    Ticket-System

    Das neue Ticket-System wird der Interaktion und gemeinsamen Ticket-Bearbeitung zwischen Support und Partner dienen. Aber auch dort wird es keine Liste aller Tickets oder Jira-Tasks geben. Das wäre schon alleine aus Datenschutzgründen nicht realisierbar (siehe oben).

    Wir nehmen euren Input natürlich auf und besprechen ihn intern. Womöglich sollten wir bei der Veröffentlichung von Known-Issues auch ein wenig offener sein. Aber die hier geforderten vollständigen Listen von Jira-Tasks oder Support-Tickets kann und wird es nicht geben.

    Eine ähnliche Anfrage zur Ansteuerung eines Türöffner-Relais haben wir vor ein paar Wochen auch gehabt:

    "Ein Kunde von uns setzt eine Türklingel ein mit folgenden Daten:Lt. seinem Elektriker wird zum Öffnen ein potentialfreier Kontakt/Schaltimpuls benötigt.
    Welches Gateway aus dem Shop kann so etwas schalten? Bei den SIP zu analog Gateways steht dabei, dass sie nicht für Türklingeln geeignet seien."

    Hier die Anwort darauf:

    "Es gibt noch das SNOM PA1+, was eigentlich für Durchsagesysteme vorgesehen ist und auch von uns untersützt / provisioniert wird:

    Snom PA1+ - Public Announcement Devices


    Das PA1+ scheint eine Art "Wunderwaffe" zu sein was die Anschlüsse angeht die gesteuert werden können, da es auch über die folgenden verfügt:


    "...together with the freely configurable relay contacts that can be controlled via SIP or DTMF..."


    Allerdings scheint es noch erforderlich zu sein, eine separate Schaltgruppe für einen Türöffner anzuschließen:

    Türöffner für SNOM PA1 SIP

    Nach meinen Verständnis müsste es damit aber möglich sein, den Türöffner via DTMF zu betätigen.

    Bitte haben Sie aber Verständnis dafür, dass wir bei der Umsetzung nur Support bis zur Provisionierung / Anbindung der PA1+ anbieten können, und nicht für die Komponenten danach.

    Falls Sie die Umsetzung testen wollen, würden wir uns aber natürlich dennoch über eine Rückmeldung freuen ob es funktioniert hat, denn Anfragen dieser Art erreichen uns auch nicht jeden Tag."

    Leider haben wir keine Rückmeldung erhalten, ob das so funktioniert hat. Das wäre durchaus interessant, da wir ja keine Elektriker sind...

    Hallo roady1969, vielen Dank für deinen Hinweis. Wenn man sich Logs ansieht, könnte das eine mögliche Ursache sein. Ich war so frei und habe dich gerade in meinem Beitrag zitiert:

    support.starface.de/forum/thread/11947/

    Hallo Meinard, wir prüfen die Fälle derzeit intern, leider kann ich dir aktuell nicht sagen wann wir eine Lösung haben. Da die DeutschlandLAN Tarife nicht mehr aktiv vermarktet werden und die DTAG alle Kunden Richtung CompanyFlex bewegen möchte, ist auch nicht sicher ob wir eine Lösung finden werden. Weitere Infos findest du im o. g. Beitrag.

    Ich glaube auch nicht, dass der SIP Trusted IP Helper bei dem Problem hilft, da er für einen anderen Fehlerfall konzipiert wurde, bei dem Invites von einer aktuell nicht bekannten IP-Adresse kommen.

    Hallo Meinard,

    der Fehler ist IMMER reproduzierbar, sobald das IVR das Gespräch annimmt.

    Bei den Tests haben die Kollegen von verschiedenen Providern (Connect, Vodafone und O2) auf der Leitung angerufen und konnten die Ansage des IVR hören. Soweit ich das aus dem Ticket herausgelesen haben, waren es "nur" ca. 8% der Telefonate die auf den Fehler gelaufen sind.

    Also muss es auch ein Stück weit mit dem Anrufer (Anlage, Provider, Carrier, etc.) selbst zu tun haben.

    Finde es etwas Schade, dass der Starfce Support dauernd auf den Dumps rum reitet, dabei haben wir doch schon bewiesen dass RTP fliest und im Dump alles zu hören ist.

    Mit einem Dump seitens der Anlage prüfen wir natürlich im ersten Schritt, ob die Anlage alles richtig macht. Das scheint hier der Fall zu sein.

    Ich verstehe nicht, warum nicht der Ansatz mit den Codecs bzw. der Aushandlung verfolgt wird

    Das prüfen wir gerade.

    oder warum das IVR Modul kein answer macht.

    Bei einem PlaybackResourceFile wird auch ein Answer ausgeführt.

    Wir werden den Fall Stück für Stück analysieren, dabei gerne auch unseren Vordienstleister bei einem Test mit involvieren. Es kann aber auch durchaus darauf hinaus laufen, dass der Fehler nicht auf der Seite von STARFACE oder STARFACE Connect liegt, sondern an irgendeiner Stelle auf dem Weg von der PBX zum Anrufer, die außerhalb unseres Einflusses liegt.

    Ich bin mir der Tatsache bewusst, dass diese Antwort die frustrierendste aller Möglichkeiten ist, aber damit wären zumindest einige Komponenten ausgeschlossen und man kann die restlichen prüfen.

    Hallo Meinard,

    ich habe mir das Ticket angesehen und auch mit den beteiligten Kollegen gesprochen. Es ist aktuell so, dass seitens der Anlage sowohl bei Positiv- als auch Negativ-Beispielen RTP-Streams gesendet werden und die TCP-Dumps im Prinzip auch identisch sind, was den Inhalt der SIP-Felder angeht. Von der Perspektive her sollte auf jeden Fall Audio beim Anrufer ankommen.

    Da der Fehler wohl in bestimmten Fällen reproduzierbar ist, hat der bearbeitende Kollege angeboten, nochmal einen Live-Test gemeinsam mit dem Vordienstleister von STARFACE Connect durchzuführen um zu prüfen, ob auch dort RTP-Streams ankommen und somit unsere Infrastruktur sauber verlassen.

    Ich würde empfehlen, diese Chance auf jeden Fall wahrzunehmen und den Test durchzuführen.

    Die Kollegen sind aktuell auch nochmal am Ticket dran und melden sich zeitnah bei dir (per E-Mail und telefonisch).

    Hallo zusammen,

    hier eine Störung in eigener Sache: STARFACE ist aktuell nicht über die bereits seit Jahren bekannten Rufnummern +49 721 151042 xxx erreichbar. Unser IT prüft den Fehler derzeit.

    Unter den seit einigen Monaten genutzten neuen Rufnummern +49 721 50959 xxx sind wir jedoch erreichbar. Diese Rufnummern kommunzieren wir seit einiger Zeit in E-Mail und auf unserer Homepage https://starface.com, sie sollten also bereits vielen Partnern bekannt sein.

    Bei Anfragen können uns unsere Partner unter der zentralen Durchwahl +49 721 50959-600 anrufen, die Kollegen verbinden gerne weiter zur entsprechenden Abteilung. Bei Support-Anfragen könnt Ihr auch wie gewohnt das Ticket-Formular nutzen, wir rufen gerne zurück.

    Aktuell ist das Anlegen neuer Clouds gestört:

    Es wird zwar eine Cloud angelegt, diese wird nach einigen Minuten aber automatisch wieder gelöscht.

    Das Cloud-Team prüft das Problem aktuell und arbeitet an einer Lösung.

    Wir informieren an dieser Stelle, sobald die Störung behoben ist.

    Edit:

    Das Problem scheint nur aufzutreten wenn Concentrator Clouds angelegt werden. Bei Clouds mit dedizierter IPv4 tritt das Problem nicht auf.

    ________________________________________________________

    [Behoben] Am 26.08.2023 um 12:00 Uhr

    Unser Cloud Team meldet, dass die Störung erfolgreich behoben wurde. Neue Clouds können wieder angelegt werden.


    Bei Clouds, an welchen am Freitag eine Aktion im Partnerportal angestoßen wurden, kann es vereinzelt zu Problemen kommen (bspw. Ausgegrauter Update Button). Sollten in diesem Zusammenhang Auffälligkeiten vorhanden sein, eröffnet bitte ein Ticket über den normalen Supportprozess.

    ________________________________________________________

    Wir wurden von Woltlab darüber informiert, dass Wartungsarbeiten an der Netzwerkinfrastruktur durchgeführt werden. Diese finden statt am

    05.09.2023

    22:00 - 22:30 Uhr

    Im genannten Zeitraum werden Wartungsarbeiten an den Netzwerkswitches durchgeführt, weshalb es zu kurzfristigen Unterbrechungen des Netzwerkverkehrs und somit der Erreichbarkeit des Forums kommen kann.

    Nach Abschluss der Arbeiten ist das Forum sofort wieder erreichbar.

    slu

    Ja, das ist leider immer unschön. Und leider haben wir gerade ein weiteres Update bekommen, dass die Wiederherstellung des Storages wohl doch noch längern dauern wird als erwartet. Es ist die Rede von ca. 4 Stunden.

    Unser NEON-Team steht im Kontakt mit dem Vordienstleister, nur leider sind uns da aktuell auch die Hände gebunden. Sobald die Systeme wieder da sind, prüfen wir sie jedoch direkt.

    slu

    Frag mich nicht warum, aber die Telefonie funktioniert wieder, wenn die Verschlüsselung für die Telefone aktiviert wird. Das ist in mehreren Fällen schon bestätigt, unter anderen auch in diesem Fall über das Ticket.

    Nur eine Mutmaßung von mir: Vielleicht hat es ja damit zu tun, dass die FritzBox nicht mehr dazwischengrätschen kann, wenn sie aufgrund der Verschlüsselung die Art des Traffics nicht mehr erkennt...?

    Edit: Und kaum redet man mit dem Team, gibt es noch weitere Ideen:

    Man sollte mal prüfen, ob auf der FritzBox noch Telefoniegeräte oder Rufnummern aktiv sind. Wenn ja, rauswerfen und die FB neustarten. Es könnte sein dass sie sich unverschlüsselt über Port 5060 zuständig für die eingehenden Invites hält, verschlüsselt über Port 5061 aber zum Telefon durchlässt.

    Dann wäre die Ursache die Konfiguration der FritzBox, nicht die LTE-Verbindung der Telekom und die Aktivierung der Verschlüsselung nur eine Art Workaround.

    Hallo FB1985

    das Problem ist schon gemeldet worden, der Fall hier scheint sehr ähnlich gelagert zu sein.

    Frage / Problem

    Eingehende Anrufe brechen nach wenigen Sekunden ab. Es wird ein LTE-Router mit einer Telekom SIM-Karte verwendet.

    Das Problem betrifft nur eingehende Anrufe. Ausgehende Gespräche funktionieren ohne Probleme.

    Wenn z.B. ein Gigacube von Vodafone verwendet wird besteht das Problem nicht.

    Lösung (Schritt für Schritt Anleitung)

    Die Telekom braucht eine aktive Verschlüsselung, daher auf der Anlage für die betroffenen Gerätetypen die Verschlüsselung aktivieren:

    pasted-from-clipboard.png