Problem mit "Ansage vor Melden"

  • Hallo Starfacer,


    ich habe ein Problem mit dem Modul "Ansage vor Melden". Unsere Version ist die 6.3.0.24.


    Folgende Symptome konnte ich beobachten:
    Wenn das Modul mit Ansage und Warteschleifenmusik aktiv ist, werden die CallerIDs gelösch. Im UCC taucht kurz kurz die richtige Nummer auf, sowohl CalledID wie auch CallerID und nach der Ansage steht nur noch die interne Gruppennummer und eine 0 da. Im Log kann man das Verhalten auch beobachten. Als Übergang habe ich das Modul erst einmal deaktiviert.


    Das Setup der Kundin ist eine überwiegende Inbound-Telefonie mit mehr als 85 Kunden, die durch CalledID identifiziert und an über Gruppen an bestimmte Mitarbeiter geleitet werden.


    Hat hier einer einen Tipp, wie man das Verhalten unterbinden kann, oder ob es mit der 6.4.x.x bereits gelöst wurde?


    Über Tipps und Hilfestellung würde ich mich sehr freuen.


    Viele Grüße
    hagenow

  • Hallo hagenow,


    das Problem ist definitiv mit 6.4.1.11 noch nicht gelöst. Support-Ticket 1061705, eröffnet am 06.12.2016, liegt seit 03.01.2017 im Status "Lösungsfindung Entwicklung".
    Bei unserem Kunden zeigte sich, daß Anrufe auf der VMB (per Mail weitergeleitet) die Nummer nicht mehr zeigen: "...Sprachmitteilung von <angerufene Nummer> : unknown ...", obwohl eine Kennung gesendet wurde.
    Leider ist die Nummer in der Mail dann doch wieder erkennbar, wenn man mit der Maus drüberfährt... deshalb hat die Lösung wohl auch keine Prio für Starface. Wir fahren also weiter ohne Ansage vor Melden. :(


    Gruß
    Schmal

  • Hallo Schmal,


    ich habe die Entwicklung in der Sache nochmal angestupst.
    Leider waren wir nicht in der Lage das Problem auf unseren Testanlagen zu reproduzieren.


    Könntest du uns im Support ein Backup deiner Anlage zur Verfügung stellen?

    Viele Grüße
    Niklas


    - Ex STARFACE Support: 2014-2020 -

  • Hallo in die Runde,
    hallo Niklas,


    ich bin an dem Spezialfall auch dran - eventuell lässt sich das über einen Umweg lösen. Vielleicht als Hinweis zur Fehlerfindung: Merkwürdigkeiten bei der Rufnummernübermittlung hatte ich zuletzt feststellen können, wenn IFMC genutzt wird, schaltet man das ab, ist (in unserem Fall) die Übermittlung der Rufnummer korrekt. Ist IFMC dagegen aktiv, kommt es zu unerwarteten Ergebnissen. Möglich, dass der Fehler genau dann nicht reproduzierbar ist, wenn dieses Merkmal im Test nicht genutzt wird.

  • ... so: es ist wohl so, dass aktuell (?) in allen Fällen, wo irgendwo ein eingehender Anruf an einen internen Benutzer oder eine Gruppe weitergegeben wird, die CalledID von der Ursprungsangabe der angerufenen öffentlichen Rufnummer durch die zuletzt "gewählte" interne Durchwahl des Benutzers ersetzt wird. Insofern man z.B. bei einer TAPI-Nutzung zur Steuerung eines CRM eben auch aus irgendeinem Grund neben der CallerID die CalledID auswerten möchte (oder muss), hat man damit "verloren".


    Was aktuell nur unklar ist: ist das ein Fehler oder funktionierte das überhaupt schon mal anders? Ich hatte die CalledID noch in keinem Fall für so eine nachrangige, externe Auswertung benötigt - entsprechend fiel das (mir) bisher auch nie auf ...

  • Hallo Ulf,
    ein BackUp wäre wirklich toll, damit wir uns das im Detail ansehen können. Wenn möglich bitte einfach per Mail an uns senden mit Verweis auf dieses Thema, danke. Wenn das BackUp größer wie 50MB ist, bitte hier kurz Bescheid geben.

  • Guten Morgen jmeyer,


    ich besprechen das gerne mit dem Kunden - nicht jeder mag gerne komplette Backups rausgeben oder kann das aus datenschutzrechtlichen Gründen. Ich habe dazu heute Nachmittag dort eh einen Termin, dann wird man sehen.


    BTW: Das Thema CalledID sollte sich aber leicht nachstellen lassen - das ist m.E. überall so.


    Grundsätzliche Frage: wenn ein Backup zur Prüfung angefordert wird soll das mir im Umkehrschluss sagen, dass eigentlich die benannten Daten (CalledID) auch unter den beschriebenen Umständen korrekt rausgehen müssten - also das Problem Seitens des Supportes nicht nachvollzogen werden kann und "nur" ein Konfigurationsproblem vermutet wird? Was würde dann denn dafür ursächlich sein, dass im benannten Fall statt der ursprünglichen externen CalledID plötzlich die intene CalledID geliefert wird?

  • Hallo Niklas,


    gerne würde ich das. Im Moment habe ich aber das Problem, daß die Sicherung die 1 GB-Grenze überschritten hat (bis zu 800 Anrufe/Tag seit November) und damit der Zugriff auf die SMB-Freigabe nachts abstürzt.
    Ich hatte im Support-Vorgang seinerzeit eine Vollsicherung bereitgestellt (war da noch um die 600 MB). Vielleicht bekommen wir ja eine andere Sicherung hin, dafür muß ich aber zunächst zum Kunden und einen USB-Datenträger anschließen.
    Und: für die Fehleridentifizierung braucht es dann wohl erst wieder die Aktivierung des Moduls. Das wiederum behindert den Kunden aber im Betrieb. Muß ich erst abklären...


    Gruß
    Schmal

  • Aktualisierung:


    In der Version 6.4.2.12 werden die Rufnummern wieder korrekt in den Mail-Weiterleitungen der VoiceMails angezeigt. Das Problem wäre somit vom Tisch, Dank an die Entwicklung!


    Aber: nach (Re)Aktivierung des Moduls klagte der Kunde über häufige Gesprächsabbrüche. Die Gegenprobe durch erneute Deaktivierung zeigte, daß es wirklich am Modul lag.


    Ich habe mir per Mail ein Protokoll der Anlage senden lassen, finde da aber (mangels Erfahrung) keinen eindeutigen Punkt, an dem der Fehler ersichtlich wäre.
    Das erneute Produzieren des Fehlers wird der Kunde nicht wollen, da seine Anrufer natürlich verärgert werden. Wie kann ich nun die Entstörung angehen?
    Da ist guter Rat teuer...


    Gruß
    Schmal

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!