Posts by cmuschitz

    Das ist wirklich interessant. Die Namensauflösung müsste nach so vielen Sekunden längst durch sein. Könnte mir keinen Grund vorstellen wieso dort das Adressbuch Probleme machen sollte.
    Wenn du den Eintrag manuell wieder im Adressbuch anlegst, tritt es dann auch wieder auf? Was steht dabei im PBX-Log?
    Wird das Adressbuch per LDAP angebunden oder ist es lokal? Sind Sonderzeichen drin oder die Daten per CSV importiert worden? Wieviel Einträge sind im Adressbuch vorhanden?

    Mit den Lifecycle-Entrypoints müsstest du dein Ziel eigentlich erreichen.


    Du musst halt zwei Funktionsebenen anlegen (unter Development bei Functions) und diese z.B. "_aktivieren" und "_deaktivieren" benennen. Dann kannst du bei den Lifecycle-Entrypoints einstellen dass "_aktivieren" ausgeführt werden soll, sobald das Modul aktiviert wird und optional "_deaktivieren" ausgeführt werden soll, wenn das Modul deaktiviert wird. Jetzt kannst du dem Benutzer die Funktionstaste "Modul aktivieren" für diese Modulinstanz zuweisen und diese damit in die Weboberfläche in den UCC-Client und auch auf das Telefon senden. Aktiviert der Benutzer das Modul jetzt (z.B. eine eigene Form einer Zeitgesteuerten Umleitung oder was auch immer du unter den Bereich "_aktivieren" jetzt einprogrammierst) dann leuchtet das Lämpchen (da das Modul aktiv ist). Deaktiviert er es (wird "_deaktivieren" ausgeführt) und anschließend geht das Lämpchen aus.
    Damit sparst du dir Umwege irgendwelche Umleitungen oder ausgehenden Anrufe abfangen zu müssen.


    Du musst übrigens nicht das Recht geben "Module zu administrieren". Es reicht unter "Tasten" das Recht "Module aktivieren" einzuräumen. Damit kann ein Modul nur ein und ausgeschaltet - nicht jedoch verändert werden. Das sollte deine Lösung sein.

    Wenn es jetzt nach dem Diensteneustart läuft, sollte ein Systemneustart nicht mehr zu Problemen führen. Wir hatten damals beim Fehler sofort einen Diensteneustart probiert - damals erfolglos. Erst nach einiger Zeit war dieser von Erfolg gekrönt. In dem Zusammenhang hatten wir auch schon Fälle gesehen, bei denen kein Telefon sich nach dem Update mehr registrieren konnte. Hier half es den Leitungsnamen umzubenennen und dadurch die Telefoniedienste neustarten zu lassen.
    Warten wir auf Starface 6.3 und harren der Dinge. Ein Update im Produktivbetrieb dürfen wir hier jedenfalls leider nicht mehr durchführen.

    Mit welcher Version tritt das Problem denn bei dir auf?


    Habe aus Jux gerade mal mit einer langen Google-Bildersuche (mit vielen Parametern) das versucht nachzustellen: funktioniert hier. Es öffnet sich ein neues Fenster mit allen übergebenen Parametern.
    sftest.JPG


    Wir verwenden allerdings auch die aktuelle Beta-Version vom UCC-Client (auch hier im Forum zu beziehen) Version 6.3.0.23.
    Vielleicht ist dort das Problem schon gefixt?

    Wir hatten den Fall bei einem Kunden mal gehabt. Da war dann in der Starface vom Kunden ein falsches Gateway eingetragen. Interessanter Weise kamen trotzdem (ein und ausgehend) Gespräche zustande - aber mit Kathastrophalen Verzögerungen und auch dem von dir beschrieben Fehlerbild. Nach Änderung war dann alles wieder in Ordnung.

    Hallo Christian,


    es hilft eine Weile (wie lange das ist, ist nicht näher definiert) zu warten und zu telefonieren und dann unter Starface im Admin - Bereich die Dienste neuzustarten.
    Hat bei uns in zwei Fällen schon geholfen. Hoffen wir, dass das bei der 5.3 der Vergangenheit angehört.

    Du kannst dich via Konsole (SSH) auf die Appliance aufschalten und dann mittels:


    tail -fn 30 /var/log/starface-update/trace.log


    dir immer die letzten 30 Zeilen der trace.log ausgeben lassen. Wenn du das gemacht hast (das Programm wird erst mit Klick von [STRG] u. [C] beendet) kannst du das Update in der Weboberfläche starten. Beim Datenbankupdate siehst du dann wesentlich genauer was (und ob) etwas gerade passiert. Vermutlich sind die Datenmengen relativ groß und man sieht kaum einen Fortschritt in der Weboberfläche (wohingegen du die genauen Punkte in der Ausgabe der Log-Datei verfolgen kannst). Klemmt es tatsächlich und alles steht für einen sehr langen Zeitraum (und auch dort in der Datei ändert sich nichts mehr), dann kann ggf. die trace.log beim Kontakt mit z.B. dem Starface-Support erste Hinweise liefern. Im wirklichen Fehlerfall ist evtl. auch der Inhalt der /var/log/starface-update/error.log interessant.


    (Hinweis: Starface-Support ist nur mit Starface-Supportvertrag kostenlos.)

    Unabhängig davon wie man zu diesem Thema jetzt stehen mag, so ist eine Anpassung (auch wenn Sie technisch möglich wäre) sicherlich eine Lizenzverletzung und dürfte rechtlich relevant sein. Wenn eine administrative Windows-Installation z.B. irgendwo genutzt wird nur um etwas zu konfigurieren, dann würde auch niemand die dafür nötige (Benutzer-)lizenz anzweifeln, auch wenn dort mit "Eingriffen in der Registrydatenbank, o.ä." sicherlich ein "Umgehen der Ansichtsweise des Herstellers" möglich wäre.


    Aber ich kann mich ansonsten den restlichen Teilnehmern hier nur anschließen: es wäre eine sinnvolle Sache den Admin getrennt anlegen/nutzen zu können.


    Grüße,
    Christopher

    Ohne Log und co. jetzt zu kennen finde ich es trotzdem seltsam:


    Nochmals zur besseren Lesbarkeit zusammengefasst:


    - die Telefone hängen alle im selben Subnetz wie die Starface
    - interne Telefonate funktionieren Störungsfrei
    - ausgehend wird über ISDN telefoniert


    Hört sich für mich im ersten Moment nach Problemen mit der ISDN-Verbindung an. Aber wie TomAnson schon sagte: am besten mal im Log schauen.

    Ich kann mich Ulf nur anschließen.


    Es ist u.U. zu befürchten, dass das nicht funktioniert. Wenn überhaupt, dann sollten aber folgende Dinge bei der Konfiguration beachtet werden:


    Den Router (nachdem er auf Werkseinstellungen gestartet wurde) OHNE Assistent und (ganz wichtig) OHNE Telefonie einrichten. Dann in den Einstellungen (vermutlich System o.ä.) schauen, dass der Easy-Support ausgeschaltet ist.


    Im nächsten Step sollte dann Port 5060 UDP und Port 5061 TCP auf die IP der Starface geleitet werden.


    Ein Stück weit kannst du die Anleitung https://knowledge.starface.de/…Date=1462362079000&api=v2 befolgen. Diese betrifft zwar den Zyxel Router der Telekom, der sich vom Speedport grob unterscheidet. Aber die generellen Wege sind ähnlich: die Ports müssen weitergeleitet werden, Easy-Support muss ausgeschaltet sein.


    Wenn das beachtet ist, kannst du SIP-Trunks bzw. SIP-Konten in der Starface für jede Leitung eintragen.


    Spannend wird es, ob der Port "geöffnet" bleibt. Falls nicht wirst du nach ausgehenden Anrufen für wenige Minuten eingehend erreichbar sein. Danach kommt der Anruf nicht mehr bei dir an. Wenn dem so ist: anderer Router / Firewall / etc., wie von Ulf schon beschrieben.



    Viele Grüße,
    Christopher

    Leicht OT, aber dann auch wieder nicht ganz: die Datei ist sehr spannend. Hier scheint mir möglicherweise noch ein Bug aufgefallen zu sein.



    Habe hier im Forum unter: http://support.starface.de/for…-legt-nach-10-Minuten-auf einen möglichen Bug gepostet, bei dem nach 10 Minuten aufgelegt wird, obwohl dauerhaft ohne Stille etwas abgespielt wird. In der WebGui habe ich für die Mailbox 30 Minuten Aufnahmezeit eingetragen. In der /etc/asterisk/voicemail.conf steht aber bei maxsecs=600 drin, was genau 10 Minuten entspricht. Ist in der WebGui ein Bug oder wie verhält sich dieser Wert? Es würde zumindest genau den (im anderen Thread) beschriebenen Fall erklären.


    Aktuell eingesetzte Starface-Version: 6.2.0.15

    Hallo Slu,


    danke für deine Antwort, aber ich glaube da besteht ein Missverständnis.


    Die Telefonie generell (egal ob ISDN, etc. oder sogar intern) funktioniert einwandfrei und fehlerfrei. Es kann normal telefoniert werden. Das Modul war nur für Fälle gedacht, bei denen man einen ausgehenden Anruf von der Starface direkt aus simulieren kann (ohne ein Telefon zu gebrauchen). Und hier wird timergestützt eine Funktion vom Modul geöffnet und mittels CallPhoneNumber die in der Modulinstanz hinterlegte Rufnummer gewählt. Das funktioniert auch alles prima. Nur nach 10 Minuten wird (scheinbar von der Starface die Modulinstanz beendet), denn es wird einfach aufgelegt. Dies passiert intern wie extern gleichermaßen und auch dann, wenn ich den Anruf zwischendurch "Park"e und wieder "Pick"e.


    Daher meine Frage: kann man diesen Timeout irgendwo im Moduldesigner abschalten oder umgehen? Oder gibt es hier eine elegantere Methode als CallPhoneNumber?



    EDIT:


    slu: kein Problem. Passiert. ;)

    Hallo Zusammen,



    wollte zu Debugzwecken gerade ein Modul schreiben, dass die in der Modulkonfiguration vorgegebene Rufnummer via CallPhoneNumber mittels Timer anruft (die Zielrufnummer ist hier auf der Starface eine Voicemailbox, die auf "30 Minuten Aufnahmezeit" steht und dann via PlaybackResourceFile immer wieder eine Ansage abspielt und zwischendurch (minütlich) prüft, ob die Verbindung noch besteht, ansonsten das Modul beendet. Das funktioniert soweit alles auch hervorragend; allerdings wird immer nach genau 10 Minuten ohne ersichtlichen Grund vom Modul / von der Starface aufgelegt. Bei CallPhoneNumber kann ich ja nur auswählen, dass der Anrufversuch (Ring Duration) so und so lange probiert werden soll. Eine laufende Verbindung wird davon aber nicht betroffen. Habe sogar probiert den Anruf kurz zu halten und wieder "auszuparken". Das Modul scheint aber trotzdem bei 10 Minuten beendet zu werden. Kann man da irgendwo was anpassen? Dachte dann, dass die Ansagen vielleicht zu lange eine Pause machen und dadurch der AB auflegt, da nicht gesprochen wird. Tatsächlich wird die Aufnahme aber mitten in einer lauten Melodie beendet.


    EDIT:
    Ist gelöst.
    Problem liegt daran, dass die Voicemailboxen scheinbar die Verbindungen nach 600 Sekunden beenden (unabhängig von der in der WebGUI bei maximaler Aufnahmedauer gewählten Zeit). Durch manuelles (nicht revisionssicheres! und nicht supportetes) ändern der /etc/asterisk/voicemail.conf und anschließendem "service asterisk restart" scheint das Problem behoben zu sein. Damit ist es zumindest kein Problem von den Modulen und kein Problem von CallPhoneNumber und damit gelöst.

    Hallo Fabian,


    wir sind Partner und haben einen Supportvertrag. Sind von Version 6.2.0.14 umgestiegen und haben auch ein sauberes Backup - von daher kein Problem. Wäre mir halt nur lieber gewesen ggf. von Hand (ohne Umwege) den Fehler beheben zu können. Logs hatten wir mittels "Jetzt senden" geschickt. Aber für ein Support-Ticket dauert es dann doch zu lange. Wir werden nachher mittels Neuinstallation und Backup zurückgehen. Module haben wir Standardmodule im Einsatz, sowie eine Hand voll eigene, die jedoch nur bei Anruf (Standard-Entrypoint) greifen. Update ist ohne Fehler durchgelaufen / hard reset gab es nicht.


    Aber wie gesagt, wir werden mittels Backup wieder zurückspielen - von daher tut es nicht weh (wenngleich es schade ist, dass das nicht durchlief).



    Gruß,
    Christopher

    Haben gerade das Update eingespielt. Es erschien die Meldung "Update erfolgreich beendet" - irgendwann war ein Login via Webseite wieder auf der Appliance möglich und brachte nur die Fehlermeldung "FunctionKey Manager not running". Haben jetzt Dienste über die Weboberfläche neu gestartet aber die Telefone kommen nicht mehr hoch.


    Ziemlich blöd.


    // EDIT //


    Habe jetzt das letzte Backup nochmals zurückgespielt (nur Stammdaten); damit sind die Telefone wieder verfügbar. Leider kommen keine Funktionstasten im UCC-Client und auf der Weboberfläche erscheint auch nur wieder "The component FunctionKeyManager is not running."


    Gibt es einen Dienst oder Befehl auf der SSH der hier Abhilfe schafft?