Posts by jochen

    Hi,


    mit folgenden Einstellungen funktionieren die Umleitungen scheinbar erstmal:


    o2 Einstellungen.png


    Tech. Infos: o2/Telefonica stört sich scheinbar daran, dass nach dem Session Progress 183 im SIP kein Ringing kommt. Das wird mit Progressinband=Never erzwungen (macht in meinen Augen aber eigentlich keinen Sinn, aber die Provider sind halt verschieden). Es kann also immer noch passieren, dass eine Umleitung nicht klappt. Gerade wenn die Zeit zwischen 183 Progress und Ringing länger dauert (5-6 Sekunden). DTMF habe ich nicht getestet.


    Grüße
    Jochen

    Hi,


    ja genau und das merkt das Modul ja auch und deswegen soll danach wieder ein Anruf rausgehen. Das macht das Modul aber nicht mehr. Zwischen Zeilen Versuch: X und Answered: false ist jeweils eigentlich ein Callphonenumber Block. Leider wird niemand angerufen.


    Grüßen
    Jochen

    Hi Fabian,


    das Log sagt leider nichts. Also keine Fehler oder ähnliches. Weder mein Log noch das modules.log. Das sollte in der Theorie aber schon so funktionieren oder habe ich dann einen kompletten Denkfehler?


    Grüße


    Jochen


    Ps: Mein Log



    [2019-08-07 14:59:59,604] INFO [NewFunction] Versuch: 1.0
    [2019-08-07 15:00:05,771] INFO [NewFunction] Answered: true
    [2019-08-07 15:00:05,772] INFO [NewFunction] Pressed:
    [2019-08-07 15:00:05,772] TRACE [NewFunction] Allowed iterations: 9999
    [2019-08-07 15:00:05,772] INFO [NewFunction] Versuch: 2.0
    [2019-08-07 15:00:05,772] INFO [NewFunction] Answered: false
    [2019-08-07 15:00:05,772] TRACE [NewFunction] Allowed iterations: 9998
    [2019-08-07 15:00:05,772] INFO [NewFunction] Versuch: 3.0
    [2019-08-07 15:00:05,772] INFO [NewFunction] Answered: false
    [2019-08-07 15:00:05,774] TRACE [NewFunction] Allowed iterations: 9997
    [2019-08-07 15:00:05,774] INFO [NewFunction] Versuch: 4.0
    [2019-08-07 15:00:05,774] INFO [NewFunction] Answered: false
    [2019-08-07 15:00:05,775] TRACE [NewFunction] Allowed iterations: 9996
    [2019-08-07 15:00:05,775] INFO [NewFunction] Versuch: 5.0
    [2019-08-07 15:00:05,775] INFO [NewFunction] Answered: false
    [2019-08-07 15:00:05,775] TRACE [NewFunction] Allowed iterations: 9995
    [2019-08-07 15:00:05,775] INFO [NewFunction] Versuch: 6.0
    [2019-08-07 15:00:05,775] INFO [NewFunction] Answered: false
    [2019-08-07 15:00:05,776] TRACE [NewFunction] Allowed iterations: 9994
    [2019-08-07 15:00:05,776] INFO [NewFunction] Versuch: 7.0
    [2019-08-07 15:00:05,776] INFO [NewFunction] Answered: false
    [2019-08-07 15:00:05,779] TRACE [NewFunction] Allowed iterations: 9993
    [2019-08-07 15:00:05,779] INFO [NewFunction] Versuch: 8.0
    [2019-08-07 15:00:05,779] INFO [NewFunction] Answered: false
    [2019-08-07 15:00:05,780] TRACE [NewFunction] Allowed iterations: 9992
    [2019-08-07 15:00:05,780] INFO [NewFunction] Versuch: 9.0
    [2019-08-07 15:00:05,780] INFO [NewFunction] Answered: false


    pps STARFACE Modules.log


    [2019-08-07 14:58:39,862] DEBUG de.vertico.starface.module.core.runtime.ModuleRuntime Calling module: CallPhoneNumberTest
    [2019-08-07 14:58:39,862] TRACE de.vertico.starface.module.core.runtime.ModuleRuntime Entry point function called: d1291263-efb1-4470-8a9e-5ea8ffe43146(NewFunction)
    [2019-08-07 14:58:49,319] INFO de.vertico.starface.module.core.runtime.functions.callHandling.audio.PlaybackResourceFile2 Call has already been completed.
    [2019-08-07 14:58:49,334] TRACE de.vertico.starface.module.core.runtime.ModuleRuntime Execution of entry point function completed in 9472ms

    Hi Fabian,


    ich habe es auf 6.4, 6.6 und 6.7 versucht ;-(. In dem Beispiel ist auch so, dass nach jedem Versuch ein Hangup kommt. Es ist auch egal, ob das Modul durch Anruf gestartet wird oder ob die Funktion von einem Timer gestartet wird.


    Grüße
    Jochen

    Hallo zusammen,



    vielleicht hat hier schon jemand mal ein ähnliches Problem gehabt und einen Workaround oder Idee. Ich versuche mich gerade an einem Modul welches bis zu einer DTMF Bestätigung nach und nach verschiedene Rufnummern anruft. Soweit eigentlich kein Problem. ... Aber wenn das Modul jemand anruft und dieser abnimmt und dieser das Gespräch auflegt, dann läuft das Modul munter weiter und macht eigentlich auch was es soll. Nur beim nächsten erreichen eines Callphonenumber Blocks macht er es einfach nicht mehr. Keine Fehlermeldung im Log oder sonstiges. Das Problem habe ich auch nur wenn der Angerufene auflegt. Legt das Modul auf, weil keine Bestätigung erfolgt, dann geht der nächste Anruf über Callphonenumber ohne Probleme.


    Muss ich hier die ganz große Keule rausholen und mit Fork arbeiten oder geht es auch anders? Hier noch Beispiel als Modul: CallPhoneNumberTest_v12.sfm


    Grüße


    Jochen

    Hallo Daniel,


    das hat auch leider erstmal weniger mit STARFACE zu tun sondern mit den eingesetzten Telefonen und deren Möglichkeiten. Wenn das Protokoll diese Möglichkeit nicht hergibt ist es einfach ein Problem welches sich nicht einfach lösen lässt. Wenn die Möglichkeit besteht, dann bin ich mir sicher wird es auch eingebaut.


    Grüße
    Jochen

    Kann ich nur bestätigen Ascom, ist sehr geil. Ein Nachteil gegenüber dem MiTel System sind die Firmware Updates der Handgeräte die nicht ohne weiteres über die Luft verteilt werden kann. Gerade die Qualität und Verarbeitung der Endgeräte ist gefühlt den anderen Herstellern überlegen. Über eine LDAP Replikation könnte man hier "relativ" einfach einen Sync ermöglichen. (Automatisches Anmelden der Telefone, Adressbuch und so weiter.)


    Grüße
    Jochen

    Hallo,


    das Problem mit Android (6.0.1) habe ich auch. Ich konnte es schon soweit eingrenzen, dass es nur von "Extern" nicht funktioniert. Bei einer Kontrolle über Wireshark konnte ich sehen, dass die Pakete gut durchkommen aber der XMPP Server entsprechend antwortet. Logs im Openfire (/opt/openfire) werden dafür leider nicht generiert.


    Mit der internen IP über VPN funktioniert die Anbindung ohne Probleme. Ideen?

    Hallo @all,


    hatte ihr schon mal ein ähnliches Problem.


    Folgender Aufbau:
    1) Modul überprüft einmal die Minute ein Postfach auf neue Emails
    2) Bei einer neuen E-Mail wird eine Rufnummer angerufen
    3) Dann wird eine Rufnummer angerufen
    4) angerufener quittiert dann mit DTMF den Anruf
    5) jetzt soll noch eine E-Mail geschrieben werden, dass der Anruf quittiert wurde und wann.


    In der Regel ist alles soweit ok, aber es kann vorgenommen, dass zwischen Schritt 4) und 5) 24 Stunden vergehen.


    [2015-12-19 05:36:34,433] DEBUG [alarmUser] Ack in external System ok
    [2015-12-19 05:37:01,638] DEBUG [checkForNewEmail] No new messages.
    ...
    [2015-12-20 05:34:03,018] DEBUG [checkForNewEmail] No new messages.
    [2015-12-20 05:35:01,757] INFO [checkMessage] User YYYY acknowledge alarm. Finished. Used Number: XXXXXXXXXX
    [2015-12-20 05:35:01,757] DEBUG [checkMessage] Bugfix for utf8 in subject


    Zwischen den Logmeldungen liegt ein Playback einer Ansage und Zuweisen von Variablen.


    In dem Modules.Log sehe ich:


    [2015-12-19 05:36:01,359] DEBUG de.vertico.starface.module.core.runtime.ModuleRuntime Calling module: Notfallalarmierung
    [2015-12-19 05:36:02,082] INFO de.vertico.starface.module.core.runtime.functions.callHandling.call.Hangup Skiping function call de.vertico.starface.module.core.runtime.functions.callHandling.call.Hangup because of AGICall == null
    [2015-12-19 05:37:01,350] DEBUG de.vertico.starface.module.core.runtime.ModuleRuntime Calling module: 3iMedia Ãœberwachungsanruf
    [2015-12-19 05:37:01,352] DEBUG de.vertico.starface.module.core.runtime.ModuleRuntime Calling module: Notfallalarmierung


    Vermutung:


    Scheinbar ein Timeout bei hängenden Komponentenaufrufen von 24 Stunden.
    Ich habe die Vermutung das irgendwie das Playback abgespielt wird und der Angerufene auflegt. Hier kommt es dann scheinbar zu einem Deadlock. Ich hatte das "Wait for User Input" auf 1 stehen. Dies habe ich mal auf 0 abgeändert. Vielleicht hilft das ja.


    Grüße


    Jochen