Posts by FabianZ

    Hallo Marco


    Ich gehe davon aus, dass das eine Non-Cloud Starface ist.


    Ich verweise kurz auf Folgendes Thema, für Proxy's: http://support.starface.de/forum/showthread.php?107-Update-schlägt-bei-mir-immer-fehl


    Überprüfe noch, ob Folgende DNS-Einträge bzw. die dahinter stehenden IP-Adressen erreichbar sind, oder gib sie für die Starface Frei:


    Quote

    license.starface.de
    updates.starface.de
    starface-cdn.de
    http://www.starface-cdn.de


    Aus Artikel: http://support.starface.de/for…nzserver&highlight=update



    MfG


    Fabian

    Hallo Sternengesicht


    Wir haben uns Intern auch immer mit diesem Problem herumgeschlagen.


    Wir haben für uns Intern ein Modul geschrieben, welches gewissen Tastentypen wie Z.B. die BLF Taste von einem Benutzer auf eine ganze Gruppe zu übertragen.


    Wir haben jeweils einen "Abteilungschef", welche jeweils die BLF Tasten definieren, die dann auf die ganze Abteilung übertragen wird.


    Da wir dies bereits beherrschen, könnte man "theoretisch" dort auch um Felder für Automatische BLF Beschriftung hinzufügen.


    An sich ist das ganze eine gute Idee, aber wenn nicht genügen Interesse von anderen Starface Partner / Benutzer besteht, so muss das ganze wohl von einem der grossen Partner (Z.B. Fluxpunkt oder O-Byte) als Modul realisiert werden


    von mir gibt's mal +1, da das ganze natürlich Arbeit abnimmt.


    MfG


    Fabian

    Quote

    Das in der Compact eingesetzte Board/BIOS würde das doch grundsätzlich hergeben ... oder etwa nicht?


    Hallo Ulf


    Ich kann das bestätigen.


    Bevor wir Hardwareanlagen ausliefern, schrauben wir diese immer zuerst auf, und Benutzen ein PIC-E Verlängerungskabel (Z.b. das Hier )


    mit einer Grafikkarte dran, um ins BIOS zu gelangen, und die Power By AC zu aktivieren.


    Ich habe soeben ein Uservoice mit dem Wunsch erfasst, dass das bei neuen Appliances vor konfiguriert sein soll.


    MfG


    Fabian

    Quote

    Starface bzw. Starface Partner sollten doch so was wissen :) Der Punkt aus aus meiner Sicht doch nicht ganz so unwichtig oder?


    Hallo Thorsten


    Wir besitzen mehr als 60 Cloud Anlagen, haben uns damit aber nie gross beschäftigt, wie genau der Anmeldevorgang bzw. Provisierungsvorgang im Hintergrund abläuft..


    Wir Benutzen ausserdem fast ausschliesslich Yealink und Gigaset Telefone.


    Am besten gibt dir die Starface hierzu Auskunft...


    MfG


    Fabian

    Quote

    Bisher versuche ich das mit »Bordmitteln« zu erschlagen. Konkret hab ich versucht über Smartwatch+ einen HTTP-Request abzusetzen, bzw. bin auch noch an den Schritt davor, das erstmal in einem beliebigen Browser zu testen. Ob das im Erfolgsfalle dann in einer eigenen App endet, wäre noch zu sehen …


    Hallo Stefan


    Du brauchst einen XML-RPC Client, um korrekt mit der Schnittstelle Kommunizieren zu können.


    Ich habe das ganze in einem Normalen Browser getestet, und bekomme ebenfalls 501 Zurück, wenn kein XML-RPC Client zur Interpretation der Antwort genutzt wird.


    https://de.wikipedia.org/wiki/XML-RPC


    MfG


    Fabian

    Hallo Thorsten.


    Die Aussage mache ich Aufgrund des Knowledge Artikels https://knowledge.starface.de/…age.action?pageId=2556035


    Grundsätzlich ist die Anmeldung vom Telefon Unverschlüsselt, ausnahme Openstage und Snom


    50080 TCP Autoprovisioning (alle 3 Arten) und Telefonmenüs (unverschlüsselt)
    50081 TCP Autoprovisioning (alle 3 Arten) für Openstage und Snom (mit TLS)


    Für UCC-Clients gibt's eine Verschlüsselte & Unverschlüsselte Methode.


    5061 TCP TLS-Verschlüsslung (STARFACE UCC-Client)
    5222 TCP Anmeldung des UCC-Clients am XMPP-Server der STARFACE ohne TLS
    5223 TCP Anmeldung des UCC-Clients am XMPP-Server der STARFACE mit TLS


    MfG


    Fabian

    Hallo Andy


    Stöber am Besten mal kurz durch deine Log-Datei von der Starface Admin ==> Server ==> Log Datei ==> Anzeige: backup , Level: ALL, ob du dort eine Fehlermeldung entdeckst.


    MfG


    Fabian

    Guten Tag Miteinander


    Ich Arbeite gerade an einem Modul, welches den Status von Besetztlampenfelder eines Benutzers Anpasst.


    Es handelt sich hierbei um einen Pseudobenutzer, dessen Besetztlampenindikation vom Modul gesteuert wird, um einen Bestimmten Modulstatus anzuzeigen.


    Ich kann den Status der Taste auf aktiv (ROT) setzen oder auf Blinkend, aber wenn ich versuche den Status auf Offline zu setzen, wir dieser auf dem Telefon sofort wieder überschrieben, während er in den anderen Oberflächen (Webinterface & UCC-Client) als Offline angezeigt wird.



    Ich erstelle hierfür die folgenden Events:
    TelephonySateChangedEvent(AccountID, TelephonyState.ACTIVE); (ROT)
    TelephonySateChangedEvent(AccountID, TelephonyState.RINGING); (Blinkend)
    TelephonySateChangedEvent(AccountID, TelephonyState.UNAVAILABLE); (Offline)


    Wobei das letzte eben bei den Telefonen nicht wirkt.


    Und nachfolgend veröffentliche ich diese via dem StarfaceEventService.


    @Starface kann der Offlinestatus nicht manuell erzwungen werden, solange der Pseudobenutzer ein Telefon besitzt?


    Mfg


    Fabian


    //edit: Dieses Thema hat sich bereits erledigt. Ich habe es herausgefunden...

    Hallo Dirk


    Wie wäre es mit Doppelter Nummernzuweisung auf dem Benutzer?


    Dann könnte man auf den verschiedenen Nummernzuweisungen Klingeln lassen, und je nachdem auf welcher Rufnummer es klingelt, klingelt ein Telefon oder nicht.


    Ich glaube ich Versinnbildliche es einfach kurz:


    Wenn der Benutzer auf 821 Angerufen wird, klingelt nur sein 1. Telefon, wenn er dann auf 822 Angerufen wird, klingelt auch sein 2. Telefon.


    Dann einfach mit Zeit Überschreitung Arbeiten 821 ==> Zeit Überschreitung 822 ==> Zeit Überschreitung Voicemailxy


    Ich weiss aber nicht, wie gut das im Bezug auf Verpasste Anrufe Funktioniert.


    MfG


    Fabian

    Guten Tag Adrian


    Zu der Sache mit dem 2. Standort.


    Die Telefone müssen entweder durch den VPN Tunnel mit der Internen Starface IP Provisioniert werden, oder die Ports: https://knowledge.starface.de/…age.action?pageId=2556035 für Provisionierung & Telefonie müssen korrekt geroutet sein.


    Wir bevorzugen den Weg über die externe IP, da das Tunneling manchmal komische Telefonieprobleme hervorruft.


    Gruss Fabian


    //edit:


    Fabian:
    Routet ihr da den ganzen Sack an Ports (80/5060/5222/50080/10.000-20.000) auf die STARFACE?
    Würde das zumindest dann auf die externe IP von Standort B beschränken.


    dominik


    Wir haben das Routing natürlich auf den Standort B beschränkt :)

    Hallo tdaber


    Danke, ich geb hier kurz an was geht


    1.Ist nur eine bestimmte Zielnummer betroffen oder alle Zielnummern?
    Es ist nur die Zielnummer mit dem Fax Betroffen, Eingehende Faxnummern variieren.


    2.Tritt das Fehlerbild bei allen eingehenden Faxen auf?
    Nein, es gibt soweit bis jetzt kein erkennbares Muster. Es ist zu Unterschiedlichen Tageszeiten, mit Unterschiedlichen Nummern, und doch nicht alle Faxe.


    3.Tritt der Fehlerbild bei allen Absendern auf?
    Ausgehende Faxe sind nicht betroffen.


    4.Ist das Ziel ein Hardwarefax oder Softwarefax?
    SF Software Fax


    5.Über welche Art von Leitung wird gefaxt?
    Es handelt sich um eine Peoplefone Leitung.


    6.Welche Umfang hat das Fax (Seitenanzahl, Qualität, Dateigröße usw.)?
    Unterschiedlich, im Beispiel das oben angegeben ist, 1 Seite aber es gibt aber auch Fälle mit mehreren Seiten.


    7.Funktioniert ein internes Testfax von Benutzer zu Benutzer?
    Einwandfrei, das ist hier aber nicht das Problem..



    Ich vermute da muss ich Fast mit der Hotline Reden, da es wie gesagt bei der Cloudanlage kein direkter SSH Zugriff möglich ist kann ich auch keine erweiterten Analyseschritte durchführen...


    Somit kann ich auch kein Logfiles O.Ä. auf Fehlermeldungen überprüfen


    MfG


    Fabian