Posts by areeh

    Danke schon mal für dein Feedback.

    Ich war der Meinung dass in der Ausbaustufe noch keine Lizenzen Notwendig sind.


    Aus dem Post von areeh lässt sich auch raus lesen dass keine Lizenzen notwendig sind.

    Bisher haben wir auch meines Wissens nach keine Lizenzen in den Ausbaustufen benötigt.

    Hallo Pius,


    ja und nein :)

    Rein von der Größenordnung her wären sie nicht zwingend nötig, aber sobald Du den Integrator verwendest (in Deinem Fall nicht zwingend nötig, aber vermutlich aus Komfortgründen gewählt), muss dieser sowie jeder davon gemanagte DECT Manager lizensiert werden.


    Gruß

    Andreas

    Hi,

    oder auch für Nicht-Partner: FAQ Nx70 - License - Gigaset PRO - Public Wiki - Confluence


    Für das genannte System sollte folgendes nötig sein:

    • 1x N870 VIRTUAL INTEGRATOR SW LICENSE S30852-H2716-X1
    • 1x N870 DECT MANAGER LICENSE S30852-H2716-X2

    (die Artikelnummern sind die Gigaset-Artikelnummern)


    Befindest Du Dich zwischen Tag 35 und 70 nach der ersten Inbetriebnahme oder letztem Factory Reset? Siehe FAQ Nx70 - License: Grace period - Gigaset PRO - Public Wiki - Confluence .


    Gruß

    Andreas

    Ja, aber da übernimmt das Handling die SF selbst, nicht der Trunk beim Provider, sonst wäre auch bei Intern-Gesprächen jedes mal ein Sprachkanal im Trunk belegt (iFMC mal außen vor).

    Um Missverständnisse auszuschließen für alle die nicht so tief im Thema stecken kurze Erklärung:

    Zuvor wurde gesagt "Da es mit verschiedenen Anbindungen/Providern Probleme gibt, kann es ja nicht an den Trunks liegen." Das bezog sich IMHO auf Connect / SIP-Provider allgemein.
    Wenn bei Cloud-Anlagen, bzw. allen Anlagen die nicht OnPremise (vor Ort beim Kunden) stehen auch Probleme mit INTERNEN Gesprächen auftreten:
    Auch interne Gespräche laufen immer über den STARFACE Server, d.h. müssen in dem Fall über eine (alle internen Gesprächsteilnehmer am gleichen Standort) oder mehrere Internetleitungen (interne Gesprächsteilnehmer an verschiedenen Standorten) geroutet werden.

    Daher könnte die Ursache dann an einem grundsätzlichen Problem mit der IP-Konnektivität zwischen allen involvierten Internertprovidern aller Kundenstandorte und dem Serverstandort (Cloud-RZ) liegen, sowie auch an dem internen Übergang zwischen verschiedenen Internet-Providern.

    200,- Euro? Damit eine Standard Funktion der Gigaset Telefone durch Starface unterstützt wird? Nix gegen euch, ihr nutzt den Markt, aber für STARFACE ein weiterer Punkt auf der Peinlichkeiten Liste.


    Sorry, nur dafür gibt kein Kunde 200,- Euro aus, die lachen mich aus wenn ich das anbiete, auch wenn das Modul mehr kann (was halt nicht gebraucht wird).


    War aber ja absehbar dass das einer der vielen Punkte "welche Standard Funktionen wollen wir explizit nicht supporten?" in der Starface Entwicklungsabteilung ist.

    Hallo EinAlex ,

    bitte mal keine vorschnellen Schlussfolgerungen und Anschuldigungen/Unterstellungen ohne genaue Kenntnis der Sachlage, danke!


    Seit STARFACE 7.2.0.5 bieten wir extra das Modul "Klingeltöne (kostenlos)" kostenlos für jedermann an.

    Wenn man dieses aktiviert, sendet die STARFACE grundsätzlich den notwendigen SIP-Header "info=alert-internal" bei internen Gesprächen an alle Endgeräte.

    Endgeräte welche das Auswerten und Erlauben dafür einen anderen Klingelton abzuspielen können das dann nutzen. Dies funktioniert gut für die Gigasets, habe ich selbst getestet.

    Was das Modul momentan noch nicht unterstützt, sind individuelle zentral vorgegebene Klingeltöne für das Gigaset System, deswegen steht Gigaset in dem Wiki-Artikel momentan auch nicht in der Liste der (vollumfänglich) unterstützten Geräte. Rein auf der Ebene intern/extern unterscheiden und den am Endgerät selbst eingestellten internen Ton nutzen geht es aber. Somit sollte Deine Anforderung erfüllt sein.


    Gruß

    Andreas

    Allerdings wenn ich mit verbundenen Wifi durch Firmengebäude spaziere und eine Sekunde kein WLAN habe, dann kappt er die Verbindung.

    Leider verbindet er sich nicht von alleine, wenn das iPhone wieder eine WLAN Verbindung hat.

    Hallo Bernhard,


    woran machst Du denn fest, dass "verbindet er sich nicht von alleine"?
    Bekommst Du danach keine Anrufe oder Chat Nachrichten? (dazu muss die App eigentlich gar nichts mitbekommen, da das ganze von extern via Push-Benachrichtigung initiiert wird und die Apple-Pushserver sollten eine geänderte IP sofort erkennen)

    Oder geht es um irgend eine optische Anzeige wenn Du aktiv in die App rein gehst?


    Gruß

    Andreas

    Hallo,

    aus Erinnerung an meine letzte Recherche vor einigen Jahren: Sofern sich in den letzten Jahren nichts geändert hat, unterstützen auch die Softwares der diversen Headset-Hersteller den Betrieb auf Terminalservern gar nicht. Es besteht ja auch kein direkter Zugriff auf das angeschlossene Gerät, ein via Terminalsitzung durchgeschliffenes USB-Gerät ist nicht das gleiche wie ein per USB direkt angeschlossenes, zumindest wenn es wie hier um hardwarenahe Ansteuerung geht.


    Tipp:

    Falls der Zugriff auf den Terminalserver via Fat-Client (PC/Notebook) erfolgt, kann dort lokal die STARFACE App für Windows oder MacOS installiert werden (dort funktioniert dann auch die Headset-Software).

    Bei einer zusätzlich auf dem Terminalserver installierten Instanz sollte der SoftPhone-Modus dann deaktiviert werden (vom Softphone-Modus auf Terminalserver raten wir sowieso grundsätzlich ab), dort wird dann der lokale Client als zu steuerndes Gerät hinterlegt. Alternativ kann der Client im Terminalserver natürlich auch ein vorhandenes Tisch-/DECT-Telefon oder iFMC-Gerät steuern.

    D.h. technisch gesehen hat der Client im Terminalserver dann ncihts mti der Audioverarbeitung und Hardware-Ansteuerung zu tun (das macht der lokale Client), sondern ist nur eine Art CTI-/Steuerungs-Client. Das ist die technisch robusteste Variante und hält auch die Terminalsitzung schön schlank (Bandbreite) und die CPU-Last auf dem Terminalserver gering.


    Gruß

    Andreas

    Hallo Andi,


    Ich möchte jetzt keine Beurteilung zu einzelnen Herstellern abgeben, aber es ist in jedem Fall eine gute Idee sich dazu kritische Gedanken zu machen.

    IMHO besonders ob ich an den Switch-Port eines Telefons einen PC hängen möchte... Auf den ersten Blick verlockend einfache Lösung, aber kaum jemand denkt dabei über mögliche Security-Aspekte nach.

    Ansonsten haben Dirk, Fabian und Roady schon viele gute Punkte genannt.


    Alternative: Keine Tischtelefone einsetzen, nur unsere Softphones!

    Dann hat Du alles aus der Hand von einem deutschen Hersteller. Da es der gleiche ist wie die PBX, solltest Du ihm bereits sowieso vertrauen.


    Läuft aber immer noch auf einem US-Betriebssystem :) Wenn man da Bedenken mit hat, dann gilt das aber auch für jede andere darauf betriebene Anwendung.


    Bitte versteht mich hier nicht falsch, ich möchte keinerlei Verschwörungstheorien befeuern und auch keinen Hersteller konkret für irgendetwas verdächtigen. Aber kritische Grundsatzgedanken sind IMHO schon durchaus sinnvoll.


    Gruß

    Andreas

    Ich selbst nutze bei solchen Anforderungen das Modul von O-Byte / Adressbuch Kontakt Importer welches sich die Adressen von einem LDAP Server in ein lokales Starface Adressbuch kopiert und daher die „normalen“ Starface Adressbücher weiter im Client angezeigt werden.

    Das ist durchaus ein Ansatz, wenn es nicht zu viele Kontakte sind.
    Spätestens ab ca. 20.000 Kontakte (keine harte Grenze, hängt von Server-Performance ab) ist jedoch aus Performance-Gründen das Umstellen von internem- auf LDAP-Adressbuch dringend empfohlen.

    Hi Peter,

    ok, das ist ein Argument. Hmmm. Wenn man so etwas ermöglichen würde, bräuchte man aber dann vermutlich zusätzlich auch noch ein Recht wie "Benutzer darf Nachbearbeitungszeit anhalten/verlängern", denn in vielen anderen Szenarien ist es vermutlich nicht gewollt, dass ein User das selbst beeinflussen kann (und sich dadurch z.B. auch missbräuchlich ewig eine Auszeit nehmen kann).

    Und die Frage ist, entscheide/ermögliche ich das wirklich pro Agent (Person), oder pro Warteschlange? Was ist wenn man mehrere Warteschlangen hat mit überlappenden Agenten und für eine Warteschlange soll es gehen, für eine andere nicht?

    Möchte man es einigermaßen passend für alle haben, macht es das in der Umsetzung dann schon einiges aufwändiger.


    Gruß

    Andreas

    Es wäre auch wünschenswert die Nachbearbeitungszeit einfach anzuhalten.

    Hallo,

    dann müsste man also einen Button drücken um sie anzuhalten, und erneut einen um sie weiter fortlaufen zu lassen?


    Wäre dann ggf. eine einfache Alternative ein Button für die Gruppen-An-/Abmeldung? Also wenn ich längere Nachbearbeitungszeit brauche, einfach temporär von der Gruppe abmelden, bin ich fertig wieder anmelden?


    Gruß

    Andreas

    Hi,


    meinst Du den Telefone- oder den Chat-Status? Welche Clients, welche Versionen?


    Wir hatten mal ein Flackern des Chat-Status bei manchen Usern während der Beta 7.2.0.4 Server + 7.2.0.149 Windows App: "Chat session instable after local network interrupt with IP change"

    Wurde im finalen Release aber gefixt.


    Gruß

    Andreas

    kann sein das das geht, aber ist das denn die Idee der app?


    es muss doch nen technischen grund dafür geben?

    Hi,


    den wird es sicher geben, habe da auch eine Vermutung:

    Macht es einen Unterschied, ob die App geöffnet (im Vordergrund Betrieb) ist, oder geschlossen bzw. im Hintergrund Betrieb?


    Ich ragte mal: Im Vordergrund geht es, in den anderen Situationen nicht?

    Dann hat es irgendwas mit den Push-Benachrichtigungen zu tun, welche notwendig sind für die Signalisierung am iPhone.


    Unsere Android App nutzt bisher keine Push-Benachrichtigungen, die iPhone App setzt sie zwingend voraus. Habe das hier irgendwo in einem älteren Thread schon mal recht ausführlich erklärt.


    Wo steht die STARFACE, Cloud oder OnPremise? Welche Version?

    Wenn OnPremise: Check mal, ob wie in Übersicht der Portnutzung der STARFACE oder im Handbuch für die iOS App angegeben, der Zugriff vom STARFACE Server auf push-cluster.starface.de:443 in der Firewall erlaubt ist.


    Gruß

    Andreas