Mobile Client, Tastenanzeige wird nicht automatisch "re-freshed"

STARFACE Mobile Client für Android 2.1, Buildnummer 177 auf Samsung S7 Android 7.0, Server 6.4.2.12

Ich habe eine Taste mit einem Modul aktivieren/deaktivieren belegt.

Drücke ich diese Taste im Android Client, dann wechselt zwar der Modulstatus (verifiziert im Windows UCC Client), die Taste auf dem Mobilclient ändert aber nicht.

Wechsle ich dann zum Beispliel auf den Tab TELEFON und wieder zurück, dann ist der Tastenstatus wieder korrekt.

Auch Anrufe oder besetzt wird in der Tastenübersicht (Kontakte) auf dem Android nicht korrekt angezeigt.

Ich denke es ist ein reines refresh Problem der Tastenanzeige.

Übrigens, hat jemand mit dieser Version die Anrufvariante Call-Back zum laufen gebracht?

Dan

Hallo Börni,

Quote from börni

Hallo Dan,

ich habe es gerade mit unserem S7 mit Android 7.0 ausprobiert.
Ich habe dabei festgestellt, dass ab und zu der Refresh nicht Zeitnahe passiert und es bis zu 10s dauern kann.
Das habe ich in unser System aufgenommen.

Danke für den Tip. Ich habe aus lauter Gewohnheit nicht gewartet da ich annahm dass die Anzeige wirklich zeitnah refreshed wird.

Quote from börni

Könntest du noch folgende Infos dazugeben:
Aktualisiert sich bei dir die Ansicht garnicht?

Doch, aber immer mit einer Verzögerung von 5-10 Sekunden.

Quote from börni

Wird bei einem weiteren Zustandwechsel (z.B.: BLF wird besetzt oder angerufen) die Ansicht aktualisiert?

Ja, aber immer mit einer Zeitverzögerung.

Quote from börni

Wie oft tritt der Fehler auf ?

Immer

Quote from börni

Call-Back:
Auf 3 Android Geräten mit verschiedenen Server Versionen getestet und hat problemlos funktioniert.
Kannst du uns dein Problem genauer beschreiben?

Meine Annahme ist dass Callback mit dem UCC Client auf dem Handy auch ohne Premium Lizenz funktionieren sollte. Ist das korrekt? Naja, auch mit UCC Premiumrecht ist etwas nicht so wie ich es erwartet hätte..

Hier ist mein Testszenario:

UCC Premium Recht vom Konto entfernt.

Szenario 1: Call-Through
- Call-Through Modul konfiguriert gemäss https://knowledge.starface.de/…age.action?pageId=6128184
Rufnummern: externe freie Nummer eingestellt und interne Nummer (übrigends wird bei der ersten Konfiguration diese Nummer im voll qualifizierten Modus angezeigt (bei mir +41 31 xxx xx 14). Nach dem Abspeichern sehe ich da aber nur noch die Kopfnummer.. vielleicht nur Kosmetik)
08.11.2017-14.21.png
Konfiguration gemäss Screenshot.. (zuerst möchte ich call-through testen)
08.11.2017-14.23.png
- im UCC Client auf Android: "Standard-Anruftyp --> Call-Through
- Der Vertrauenswürdige Anrufer *xxxx22 ist meine Mobilnummer. Dadurch fällt die Abfrage des Authentifizierungscode weg, nehm ich an..
- Die Signalisierungsnummer ist die Firmennummer. Der entsprechende Testbenutzer darf sie auch benutzen

Test 1: Anrufversuch vom UCC auf dem Handy, Zielnummer 0041xxxxxx58: Funktioniert wie erwartet. Das Rufaufbau dauert eine Weile, wird aber über GSM an die konfigurierte Call-Through Nummer +41 31 xxx xx 14 und von der Starface an die Zielnummer aufgebaut. Die korrekte Signalisierungsnummer wird mitgegeben. Ich muss nichts manuell eingeben.

Szenario 2: Call-Back
- Wie Scenario 1, aber diesmal mit Call-Back.
- Modulkonfiguration gemäss Screenshot:
08.11.2017-14.48.png
- im UCC Client auf Android: "Standard-Anruftyp --> Call-Back

Test 2: Anrufversuch vom UCC auf dem Handy, Zielnummer 0041xxxxxx58: Funktioniert nicht wie erwartet. Der Rufaufbau erfolgt *nicht* über GSM, aber anscheinend über SIP. Am Mobile scheint überhaupt nichts zu passieren... (read on).

Das Modullog zeigt etwas interessantes:
[2017-08-11 14:50:23,976] INFO [main] Extern: 0041xxxxxx59 Intern: 52
[2017-08-11 14:50:23,977] INFO [main] Incoming call. Callnumber: 0041xxxxxxx59 Caller name: Daniel Huber
[2017-08-11 14:50:31,245] INFO [main] Calling back caller: 0041xxxxxxx59
[2017-08-11 14:50:58,434] DEBUG [authenticate] Auth attemp
[2017-08-11 14:50:58,502] INFO [PlaybackResourceFile] PlaybackResourceFile: Resource core/sf-auth-pass-short.sln is 8K, but was found in 16K (de)
[2017-08-11 14:51:00,403] INFO [PlaybackResourceFile] PlaybackResourceFile: Resource core/sf-auth-poundkey.sln is 8K, but was found in 16K (de)
[2017-08-11 14:51:07,569] DEBUG [authenticate] Auth attemp
[2017-08-11 14:51:07,599] INFO [PlaybackResourceFile] PlaybackResourceFile: Resource core/sf-auth-pass-short.sln is 8K, but was found in 16K (de)
[2017-08-11 14:51:09,450] INFO [PlaybackResourceFile] PlaybackResourceFile: Resource core/sf-auth-poundkey.sln is 8K, but was found in 16K (de)

0041xxxxxx59 ist die primäre externe Rufnummer es Kontos von dem ich teste.
Der Rückruf erfolgt also zum UCC Mobilclient, der aber den Anruf *nicht* entgegennimmt. Tatsächlich passiert überhaupt nichts auf dem UCC Mobilteil. Kein Rufton, nichts. Hier ist wahrscheinlich das Hauptproblem. (mit UCC Premiumrecht eingeschaltet, höre ich zumindest den Rufton).
Ich habe an diesem Konto noch ein T46 und den Windows UCC Client am laufen. Nehme ich dort den Anruf entgegen, werde ich nach dem Passwort und der Zielnummer gefragt. Aber das ist ja nicht was ich will..

Die Logik scheint ok zu sein, aber der Rückruf der Starface wird von originalen Anrufer, dem UCC Mobilclient einfach nicht entgegengenommen.

Wenn ich die UCC Premiumfunktion wieder zuordne, höre ich nun auf dem UCC Mobilclient denn Rufton und kann den Anruf entgegennehmen. Allerdings werde ich dann nach dem Passwort und der Zielnummer gefragt. Ergänze ich die Nummer 0041xxxxxx59 im Modul bei den Vertrauenswürdigen Anrufern, dann wird nur die Zielnummer angefragt...

Ich denke da ist etwas nicht wirklich so wie es sein sollte.

Wenn Call-Back eingestellt ist, dann sollte der UCC Client den Rückruf meiner Meinung automatisch entgegennehmen. Und der Client sollte die ursprünglich gewählte Zielnummer dann selbstständig eingeben, ohne dass der Anrufer irgendwas machen muss.
Funktioniert ja beim Call-Trhough ähnlich. DOrt muss ich die Ziuelnummer auch nicht nochmal eingeben.

Szenario 3: Alles Manuell mit GSM
- Gleiches Vorgehen wie Szenario 2, aber diesmal alles manuell und über GSM. Call-Back funktioniert wie erwartet, aber natürlich muss ich die Zielnummer manuell eingeben..

Daniel

Hallo Börni,
Danke für die Erklärungen. Jetzt ist alles klar.

Was ist mit dem urprünglichen Problem mit der Zeitverzögerung des Statusupdates?

Ich werde auch gleich noch ein Problem auf dem iOS Client in einem separaten Artikel aufgreifen..
Grüess
Daniel

Ok. Hatte ich übersehen.
Vielen Dank