Hallo Daniel,
du führst einen attended transfere durch, -> du hast einen gehaltenen Anruf und grabbst einen
deine Kunde einen blind transfere -> der gehaltene Anruf wird "blind" auf den gegrabbten Anruf verbunden, da auf der BLF nun der eingehende Anruf auf dessen Benutzer liegt.
Das kann je nach Telefon und gleichem Ablauf anderst ablaufen, da sich da auch Telefone unterschiedlich verhalten (Telefonspezifisch ob blind oder attended).
Gruß Börni
Hallo Daniel,
es ist kein Fehler der Starface, die macht in diesem Falle auch alles korrekt. Sie führt in diesem Moment die Aktion des Users aus, ist nur den meisten nicht bewusst.
Es ist nur unglücklich, wenn jemand gerade eine BLF drückt und genau in diesem Moment, dieser User angerufen wird.
Somit wird aus dem Anruf / attended transfere / blind transfere ein Call-grab mit den oben genannten Folgen.
D.h. über eine blinkende BLF (eingehender Anruf auf Benutzer) lässt sich nun nicht mehr der Benutzer anrufen, sondern es ist nun möglich seinen eingehenden Anruf zu übernehmen. -> Call-grab
Das kannst du (und auch dein Kunde!) im Benutzerhandbuch unter BLF nachlesen, somit sollte diese Situation geklärt sein.
Ich denke nicht, dass über Halten + Transfere dieses Verhalten besser wird, es wird genau in diesem Fall das gleiche passieren.
Abhilfe könnte sein sich die Funktionen einer BLF anzusehen (wie oben schon geschrieben).
Ich könnte mir vorstellen, dass dieses Szenario durch Benutzen einer Direktwahl Taste nicht auftritt, da diese keine Call-grab Funktion hat.
Gruß Börni
Hallo Daniel,
das kommt auf die Konstellation an und auch wie genau der Transfere durchgeführt wird.
Das ist uns schon bekannt und konnten wir schon nachvollziehen.
Einen Lösungsansatz haben wir bereits, aber es ist noch unklar, wann wir ihn umsetzen.
Gruß Börni
Hallo Daniel,
Das habe ich in unser System aufgenommen.
d.h. wir haben das auf dem Schirm und wird durch unseren internen Ablauf bearbeitet.
Gruß
Börni
Hallo Fabian,
da müssen wir ran.
Laut log scheint es so zu sein als wäre das Logo, wie vermutet, nicht vorhanden.
Wenn möglich in dem Ticket auf dieses Thema verlinken.
Gruß
Börni
Hallo Fabian,
ist das Problem bei allen E-Mail's?
Auf die schnelle:
- mail log auf DEBUG stellen, speichern und eine 'defekte' Mail senden. Log mit Angabe der Uhrzeit der Mail posten. Nich vergessen das Log wieder auf INFO zu stellen und Mailadressen unkenntlich machen.
- schauen ob das Starface Logo vorhanden ist: /var/lib/tomcat6/webapps/localhost/starface/WEB-INF/filetemplates/mailtemplates/img/sflogo.png wenn möglich runterladen und anschauen
evt. (warum auch immer) ist das png defekt
Ich denke wenn dabei nichts rauskommt müsste man uns über den Support ein Backup zukommen lassen.
Gruß
Börni
Hallo Daniel,
du musst folgende Fälle unterscheiden:
1) Call-Through: ist zum Signalisieren einer Nummer auf der Starface
2) Call-Through mit Call-Back: ist zum Signalisieren einer Nummer auf der Starface. Das Modul ruft dich zurück (um keine größeren Kosten für das Handy zu erzeugen).
3) Call-Back: ist der Reguläre Call-Back für deinen Benutzer. Es wird somit die Nummer deines Benutzers signalisiert.
Zu 1): das passt und funktioniert korrekt.
Zu 2): du willst eigentlich diesen Fall, aber du versuchst es über 3).
Da du Call-Through mit Call-Back möchtest ist es immernoch ein Call-Through, da du die eingetragene Nummer im Modul signalisieren willst.
Deshalb muss der Anruf auch über Call-Through gestarten werden in der Android App.
Wenn du bei eingeschaltetem Call-Back (im Call-Through Modul) auf Call-Through anrufst, wirst du aufgelegt und auf dieser Nummer zurückgerufen.
Zu 3): Hier musst du unter Call-Back Nummer deine Handy Nummer eingeben.
Rufst du nun jemand über Call-Back an, wird die Call-Back Nummer sowie die Zielrufnummer an die Starface übermittelt.
Diese starten ein Anruf zu deiner Call-Back Nummer (der dann über GSM kommt), der wie eine Regulärer Anruf auf dein Handy eingeht.
Nimmst du diesen nun an, wird durch die Starface die Zielrufnummer angerufen und deine Reguläre signalisierte Rufnummer des Benutzers signalisiert.
Gruß
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.
Könntest du noch folgende Infos dazugeben:
Aktualisiert sich bei dir die Ansicht garnicht?
Wird bei einem weiteren Zustandwechsel (z.B.: BLF wird besetzt oder angerufen) die Ansicht aktualisiert?
Wie oft tritt der Fehler auf ?
Call-Back:
Auf 3 Android Geräten mit verschiedenen Server Versionen getestet und hat problemlos funktioniert.
Kannst du uns dein Problem genauer beschreiben?
Gruß
Börni
Hallo zusammen,
aus Erfahrung kann ich sagen, so ist das zumindest auf meiner ehemaligen zuständigen Leitstellen gewesen (Feuerwehr), dass man sich dort auf der regulären Nummer der Leitstelle genau für dieses Thema melden konnte.
Da wurde dann ein ein Termin vereinbart (Zeiten an denen normalerweise wenige Notrufe eingehen) und gut wars. Man sollte aber vorher überprüfen, dass die Sprache nach extern in beide Richtungen funktioniert.
Wie das natürlich bei anderen Leitstellen gehandhabt wird... gute Frage, ich denke da hilft ein Anruf bei dieser.
Ich denke Fabian's Beitrag ist nichts mehr hinzuzufügen.
Gruß Börni
Hallo Marco,
die Starface übermittelt korrekterweise 110 an dein SIP-Provider.
Notruf Standard/"Norm" ist ohne Landes- und Ortsvorwahl!
Weshalb der Provider das andere Format möchte ist mir unklar.
Der Notruf hat somit nie funktioniert und wurde auch nach seiner Einrichtung nicht getestet.
Du hast die Möglichkeit dich an einen Moduldesigner zu wenden, der dir eine Lösung baut.
Es ist übrigens keine Lösung "+49..." als Notrufnummer einzutragen, da Ihr diese dann genau so wählen müsst.
Gruß Börni
Hallo d i r k,
du kannst unter "Einstellungen -> Logging aktivieren" das Logging aktivieren.
Das Logfile findest du unter: "/Android/data/de.starface/files/ErrorLogs/log.txt".
Nachdem die App erneut die Login-Daten verloren hat oder abgestürzt ist den Inhalt hier posten.
Folgende Informationen sind zu dem Logfile auch hilfreich:
- Datum und Uhrzeit des Fehlers
- Server Version der Starface
- Auffällige Randbedingungen z.B.: wechsel von W-LAN zu Mobile-Daten o.ä.
Dann kann ich mir das mal anschauen.
Gruß Börni
Callback ist tatsächlich verfügbar ABER eine visuelle Bestätigung fehlt immer noch.
Man kann einfach nicht erkennen, ob der Callback-Aufruf erfolgt ist...
Hallo David,
Ich habe dein Wunsch als Verbesserung in unser System aufgenommen.
Gruß Börni
Wenn die UCC-Client App im Hintergrund geöffnet ist, unterdrückt dies bei der App Navigon den Lautsprechermodus.
Hallo Fabian,
kannst du mir weitere Infos zukommen lassen?
Ist das nur während eines aktiven Gespräches oder wenn die UCC App im Hintergrund ist ohne aktives Gespräch?
Betrifft das auch weitere Apps (z.B. WhatsApp, YouTube)?
Ich konnte dieses Verhalten teilweise nachvollziehen aber nur während eines aktiven Gespräches, welches in den Hintergrund geschoben wurde.
Gruß Börni
