Ein Kollege bei uns hat mit dem Desktop Client Version 61 919 das Problem, das Gespräche bei einem Blind Transfer nicht angenommen werden können, wenn ich das Gespräch von meinem Yealink T48 an ihn weiterleite. Der Annahme Button ist nicht da (siehe Bild). Bei einem Transfer mit vorheriger Rücksprache ist das Annehmen möglich.
Mache ich einen Blind Transfer mit der Mobile App, oder dem Desktop Client funktioniert die Rufannahme beim Kollegen auch beim Blind Transfer.
Ich habe hierzu auch bereits ein Ticket eröffnet, wollte aber hier im Forum mal horchen, ob jemand das Problem nachvollziehen kann, bzw. dieses schon bei ihm aufgetaucht ist?
Könnte es sein, dass es sich dabei um dasselbe Problem handelt, das ich selbst hatte (Anruf kann nach Pickup nicht wieder "zurück" transferiert werden)? Ich bin leider aufgrund meiner Auslastung nicht dazu gekommen, es weiter zu verfolgen und verwende aus diesem Grund wieder mein Yealink… Der Support konnte es jedenfalls nicht nachvollziehen.
Hallo zusammen,
welche Server-Version ist denn bei euch im Einsatz? Sind den betroffenen Benutzern irgendwelche vorher/nachher Aktionen zugewiesen?
Tritt das auch bei direkten, internen Anrufen auf oder ist das auf Warteschlangen oder externe Anrufer beschränkt?
Die Client-Logs mit --logXmppMessages wären hier hilfreich.
Extern Nachher Aktion existiert, wenn auf der Durchwahl besetzt ist, oder nach Timeout nicht an das Telefon gegangen wird, oder das Endgerät ncht registriert sein sollte, wird auf die Zentral eabgeworfen.
Es tritt nur auf, wenn ich ein Gespräch blind von meinem Yealink Desktop Telefon durchstelle.
Client Log kann ich in der kommenden Woche nachliefern. Das Log vom angerufenen nehme ich an!?
Danke - ich konnte das Problem nun nachstellen. Anscheinen ist die genaue Bedienung am Yealink ausschlaggebend, was aber wohl auch wieder von Modell und Firmware abhängt.
Kaputter Transfer:
Ich nehme den eingehenden Anruf am Yealink an, spreche mit dem Anrufer, drücke “Transferieren”, wähle die Nummer an die transferiert werden soll und drücke die OK-Taste (oder warte bis das Yealink automatisch wählt). Nach einem erneutem “Transferieren” ist der Anruf weg und beim Ziel wird der Anruf als bereits laufendes Gespräch gezeigt.
Funktionierender Transfer:
Ich nehme den eingehenden Anruf am Yealink an, spreche mit dem Anrufer, drücke “Transferieren”, wähle die Nummer an die transferiert werden soll und drücke den grünen “Transferieren”-Button im Bildschirm.
Verhält sich das bei euch ähnlich? Ggf. könnte es hier helfen, die Yealink-Einstellung transfer.semi_attend_tran_enable = 0 zu setzen.
Ich habe den Fehler wie folgt festgestellt: Während ich ein Gespräch führe wähle ich die BLF Taste des Kollegen am Yealink T48, während der interne Teilnehmer gerufen wird, betätige ich “Weiterleiten” auf dem Display des Telefons. Es klingelt das transferierte Gespräch im Desktop Client, aber der Kollege kann es am Desktop Client nicht annehmen, weil der grüne Hörer zum annehmen des Telefonats nicht angezeigt wird.
Das war auch reproduzierbar. Ein transfer.semi_attend_tran_enable = 0 scheint auch hier die Situation etwas zu verbessern, allerdings kann es sein, dass das Gespräch in seltenen Fällen nicht ankommt. Wir forschen hier noch genauer nach.
Wenn ich eine Chat Nachricht erhalte und dann noch eine und noch vom selben Kollegen, dann habe ich drei Benachrichtigungsfester. Irgendwie unschön, oder?
Reicht es nicht aus, wenn man ein Pop Up bekommt? Man kann ja in den Client wechseln…
Das Verhalten konnte ich heute auch nachvollziehen, allerdings mit einer Cloud 19.04 in Verbindung mit der aktuellen iOS-App (keine Beta) und einer M900 mit einem M70.
Hallo @IT-Service,
wir haben diesbezüglich bereits ein Ticket. Mehrere Benachrichtigungen sollen damit dann zu einem Hinweis zusammengefasst werden, sofern dies möglich ist.
