Posts by fwolf

    Nein, Du richtest genau eine Modulkonfiguration ein (mehrere Konfigurationen werden nicht unterstützt).
    Es können sich User aus beliebigen Tenants mit dieser einen Modulinstanz verbinden.

    Für einen Tenant kannst Du Autoprovisionierung aktivieren, indem Du dich im Modul mit dieser Microsoft-Umgebung verbindest. Hier bietet sich also an, den Tenant mit den meisten Usern zu verwenden.

    Für alle anderen Tenants, gibt man im Client einfach den PBX-Namen und -Schlüssel, Benutzername und Passwort an.

    Wenn man für alle Tenants die Autoprovisionierung möchte, müßte man

    • entweder die Autprovisionierungsdaten per Graph Explorer manuell in die jeweiligen Tenants schreiben oder
    • sich der Reihe nach an den verschiedenen Tenants anmelden, so dass das Modul die Daten dort hineinschreibt.


    Wie schon gesagt: Es gibt lediglich die Einschränkung, dass die Präsenzsynchronisation nur mit dem Tenant funktioniert, mit dem man sich derzeit angemeldet hat.

    Hier gibt es vermutlich ein Missverständnis.

    Das STARFACE MS Teams Integrationsmodul benötigt keine Verbindung zu einem Microsoft Tenant.
    Die Anmeldung im Modul dient nur dazu, die Autoprovisionierungsdaten in den Tenant zu schreiben, so dass Clients diese Daten auslesen und sich verbinden können. Man kann im Client jedoch beliebige Daten angeben.

    Es können sich also beliebige User aus beliebigen Tenants alle an der selben STARFACE anmelden.

    Eine Einschränkung wird es zukünftig (in der aktuellen Version gibt es keine Einschränkung) nur in Bezug auf den integrierten Presence Sync geben. Dieser wird modulseitig Daten aus dem einen, angegebenen Tenant lesen. Ein Presence Sync wird also später nicht mit mehreren Tenants funktionieren.

    Dann sollte die CA doch als Download über das WebGUI angeboten werden (ja ich komme auch über SSH ran...)

    Denk dran, dass die PEM-Datei den Private-Key enthält!
    Wäre diese über die Weboberfläche herunterladbar, wäre das ein ernstes Problem. Aber ja, das Zertifikat selbst sollte herunterladbar sein...

    Wenn die Starface App das Zertifikat nicht validiert (was technische nicht geht da pro Anlage generiert) würde ich diese nicht über eine normale Internetverbindung benutzten. Ja die Kommunikation ist verschlüsselt keine Frage, aber so richtig TLS ist das dann nicht weil MITM nicht auffallen würden.

    Ja richtig, Verschlüsselung selbst ist wenig wert, wenn ein MITM dazwischen sitzt... und das ist genau der Zweck einer Zertifikateprüfung.
    Das nächste Problem ist jedoch: Vielleicht tummeln sich in den knapp 80 CA-Zertifikaten, die auf dem Telefon vorinstalliert sind, auch CAs, die vielleicht nicht vertrauenswürdig sind.
    Dir geht es aber primär um die App/den Client, richtig?

    Es handelt sich bei dem CA-Zertifikat nicht um eine externe STARFACE CA, sondern um ein von der Anlage erzeugtes Zertifikat, das im Rahmen der Provisionierung auf die Endgeräte konfiguriert wird (sofern unter Telefone/Sicherheit die "Verschlüsselung für Provisionierung, Menüs und Telefonie" aktiviert wird).

    Deshalb haben Anlagen-/CA-Zertifikat auch das Erstellungsdatum der Installation und ein Ablaufdatum 20 Jahre in der Zukunft.

    Ob ein Client das Zertifikat validiert, ist Angelegenheit des Clients – so wie es Angelegenheit der Anlage ist, ein mögliches Clientzertifikat zu validieren.
    Mir wäre nicht bekannt, dass der UCC-Client eine solche Validierung durchführt; ich nehme es aber nicht an, da der Client völlig autark installiert werden kann und die UCI keine Zertifikate ausrollt.

    Was deine Frage bzgl. der Installation des Zertifikats angeht:
    Du kannst dein eigenes Zertifikat installieren, dieses muß dann aber von einer vertrauenswürdigen CA signiert worden sein – oder Du machst es wie die STARFACE und packst es händisch in die Liste der vom Telefon akzeptierten CAs.

    Ich habe mich damit mal ein bischen beschäftigt, weil ich versucht habe mit WIreshark SIPS / SRTP Verkehr zu entschlüsseln.

    Für Asterisk wird ein separates Asterisk.pem file verwendet.

    /etc/asterisk/keys/asterisk.pem
    /var/starface/srtpcerts/asterisk.pem

    Diese werden verwendet, um die TLS Zertifiakte für SIPS und SRPT zu erstellen.

    Nein, das PEM-File wird nicht zum Erstellen des TLS-Zertifikats verwendet, sondern es enthält das CA-Zertifikat, welches gleichzeitig das Server-Zertifikat ist UND den zugehörigen Private Key. Es ist also das Ergebnis einer Erstellung. Das sieht man daran, dass im subject die IP-Adresse der Anlage als commonName eingetragen ist.

    Mit diesem Zertifikat weist sich die STARFACE-Anlage also gegenüber den Telefonen aus.

    So wie ichs verstanden habe, führt das Ersetzen dieses Zertifikats dazu, dass alle bestehenden Geräte mit SIPS sich nicht mehr verbinden können, es sei denn, sie bekommen das neue TLS Zertifikat irgendiwe zugewiesen.

    Das liegt nur daran, dass im Rahmen der Provisionierung das Endgerät so konfiguriert wird, dass es nur vertrauenswürdige Zertifikate akzeptiert und das von der STARFACE selbst erstellte CA-/Server-Zertifikat in die Liste der benutzerdefinierten vertrauenswürdigen CAs aufgenommen wurde.

    Ansonsten sind noch knapp 80 von Yealink integrierte Zertifikate vertrauenswürdig. Wenn man das Zertifikat ersetzt, muß man lediglich schauen, dass es entweder von einer vertrauenswürdigen CA (aus der Liste der Integrierten) signiert wurde oder man ist selbst die CA und muß sein signierendes CA-Zertifikat dann auf die Telefone provisionieren.

    image.png

    Wir verwenden für solche Themen immer das estos MetaDirectory als zwischengeschaltetes LDAP.
    Das hat den Vorteil, dass das MetaDirectory aus verschiedenen Quellen (AD/LDAP Office365, SQL-Datenbanken, etc.) die Kontakte einsammelt, normiert und dann einheitlich per LDAP verschiedensten Nutzern bereitstellt.

    Die STARFACE bekommt im Bereich "Adressbuch" dann das MetaDirectory eingetragen.

    Im MetaDirectory selbst läßt sich beliebig filtern, Einträge manipulieren und anhand von Rechten differenzieren.

    Der Import-Konnektor des MetaDirectory kann beliebige Feldzuweisungen durchführen oder Filter anwenden.

    Das hängt natürlich davon ab, was im Telefon konfiguriert ist. Für Cloud-Anlagen wird in der Regel ein kürzeres Reregistrierungsintervall konfiguriert.

    Die snoms schicken nach Ablauf von 50% des konfigurierten Intervalls ein Re-INVITE. Standardmäßig sind 3600s konfiguriert, der kleinste Wert im snom sind 90s (SIP-Session-Timer).

    Im Default wird also unabhängig von irgendwelchen Anrufen, alle 1800s ein ausgehendes Paket erzeugt.

    Also bei einem IP-Adresskonflikt ist es klar, dass die Telefone die Registrierung verlieren, denn die Antwortpakete kommen nicht mehr zuverlässig an.

    Warum werden Endgerätenetzwerkkonfigurationen überhaupt statisch vergeben? Ein DHCP-Server macht das besser, als jeder Mensch.

    Um die Hypothese zu überprüfen, muß man sich während des reproduzierten Fehlerfalls die ARP-Tabelle anschauen.

    Alternativ könnte noch irgendein IP-Blacklisting zuschlagen (IDS/IPS?!).

    Ihr stellt die IP des Telefons auf eine statisch um, nachdem es per DHCP eine zugewiesen bekommen hat?

    Für mich klingt es, als ob ihr euch dadurch IP-Adresskonflikte ins Haus holt.

    Lasst das Telefon doch auf DHCP stehen – ansonsten müsst ihr sicherstellen, dass die statische IP vom DHCP-Server nicht vergeben wird (z.B. per ARP-Check oder Einschränkung des Lease-Bereichs) und dass ihr bestimmte Adressen nicht versehentlich doppelt vergebt.

    Ein IP-Adresskonflikt hat genau die beschriebene Symptomatik.

    Das ist ein ganz klassisches Firewall-/NAT-Routing-Thema im Home-Office.

    Beim Verbindungsaufbau zum Telefon, muß eine Verbindung von Extern durch den NAT-Router und dessen Firewall zum Endgerät.

    Das setzt voraus, dass der Router für diese eingehenden Pakete eine zuvor ausgehende Verbindung in seiner Session-Table gespeichert hat. "Vergisst" der Router diese Session, werden die eingehenden Pakete abgelehnt.

    Die Lösung ist also: UDP-Session-Timeout auf dem Router im Home-Office erhöhen oder dafür sorgen, dass das Telefon in kürzeren Intervallen (die kürzer sind als der Session-Timeout) ausgehende Pakete an die STARFACE versendet.

    Es geht um die Kommunikation des Frontends (grafische Oberfläche im Browser) mit dem Modul-Backend (in der STARFACE).

    Wenn diese Kommunikation nicht funktioniert, dann hat das Frontend nichts anzuzeigen.

    Der häufigste Grund für die Fehlermeldung ist, dass die Modulkonfiguration deaktiviert ist oder umbenannt wurde.

    Unterstützt ist von uns offiziell nur Chrome bzw. Chromium Engines (das hängt mit der Verbreitung zusammen); prinzipiell wäre ein zu alter oder inkompatibler Browser ebenfalls eine denkbare Ursache.

    Moin Felix!

    SUOTA liefert ja die Firmware für die Mobilteile.

    Wenn – laut den Berichten (hier im Forum) – einzelne Basisstationen mit einer Memory Overflow Exception crashen, liegt das dann vielleicht weniger an der konkreten Basis, als an einem Mobilteil, dass mit dieser Basis verbunden ist und für das SUOTA Firmware bereitstellen soll?

    Sind neue Firmwares zu groß für die N720 oder müssen wir bei der N720 ein Problem mit der Speicheralloziierung annehmen (was ein paar "Red Flags" hissen könnte)?