[Bug] Starface verliert Call bei bestimmter Anzahl von Parkvorgängen

  • Kurze Zusammenfassung der Problematik:
    Seit unbekannter Zeit hat die Starface ein Problem mit den Parking Lots,
    das führt dazu das die Gespräche einfach heraus fliegen.


    Vielleicht erkennt durch diesen Thread jemand ein anderes Problem das auf diesem beruht
    und wir können den Fehler so schneller eingrenzen.



    Möglichkeiten den Bug zu reproduzieren:
    1) Im Callmanager
    * Gespräch annehmen und dann im WebGUI Callmanager auf "Anruf halten"
    * Gespräch wieder annehmen und wieder auf "Anruf halten"
    -> beim neunten mal "Anruf halten" ist das Gespräch weg


    2) Über ein Modul
    * Modul Nummer zuweisen und darauf Anrufen
    -> beim 19. ParkCall fliegt das Gespräch raus


    Es spielt keine Rolle wie hoch man die Pausen setzt, es ist reproduzierbar.


    Stresstest_Modul.jpg


    --------------------------------------------------------------------------------------------------------------------------------------


    Lange Geschichte:
    Mit dem Update auf die Starface 6.5.1.2 haben wir immer wieder Gespräche verloren [1].
    Im Nachhinein ist mir aufgefallen das wir auch verschiedene Ansagen in die iQueue eingebaut haben,
    damit haben wir die Anzahl der Parkvorgänge massiv erhöht.


    Beim annehmen eines Gespräches aus der iQueue und einer Rückfrage über den Callmanager im WebGUI ist genau
    in diesem Moment der Call herausgefallen, aber nicht immer.


    Es hat sich dann herausgestellt das die Probleme auch schon mit der 6.5.0.30 vorhanden waren.
    Das komische, bis jetzt sind wir wohl der einzigste Kunde der dieses Problem hat obwohl der Bug auf
    verschiedenen Anlagen reproduzierbar ist.
    Es ist für mich auch nicht zu erklären warum es immer nach 9 bzw. 19 Durchläufen herausfliegt.


    Wir stehen schon seit einigen Wochen mit Starface in Kontakt, vielen Dank an Tom und die Kollegen für die Hilfe.


    [1] https://support.starface.de/fo…en-evtl-iQueue(-)-Problem

    Grüße
    slu


    ---
    Ich bin kein Starface Partner - zufriedener Starface Anwender seit Anfang 2008.

    Meine Module: Einfache Community Blacklist

    Einmal editiert, zuletzt von slu ()

  • Dieser Bug ist absolut faszinierend weil er auf allen Starface Anlagen vorhanden ist, aber auch sehr mysteriös weil er nur bei uns auffällt.

  • slu:


    Zitat

    Dieser Bug ist absolut faszinierend weil er auf allen Starface Anlagen vorhanden ist, aber auch sehr mysteriös weil er nur bei uns auffällt.


    Ja - mir war das bisher tatsächlich so noch nie untergekommen. Die von Dir gezeigte Herangehensweise ist aber tatsächlich komplett anders, als ein von mir genutzter Ansatz. Ich bin gerade am Analysieren, ob da möglicheriweise der entscheidende Punkt liegt. Wegen eines gerade laufenden größeren Starface-Projektes kann ich da nur leider nicht ganz intensiv dran bleiben, habe das aber aktiv auf dem Tisch ... :cool:


    In Deinem Script lässt sich das in jedem Fall hier auch nachvollziehen - möglich, das ein bestimmter Ansatz auch in der iQueue vergleichbar umgesetzt wird. Ich mag mich aber auch irren - also bitte nicht zu früh eine verbindliche Antwort erwarten. Ich muss zunächst mal einen Stresstest mit dem anderen Umsetzungsweg initiieren - dann sieht man mehr. Vielleicht ist das zufälligerweise nur wirklich noch nie aufgefallen.


    Spannend bei Deinem Ansatz: es ist auf den ersten Blick gar kein "Fehler" erkennbar - aber konsequent wird an immer gleicher Stelle abgebrochen und das bei einem Banalsriptablauf ... :confused:

  • Hallo Slu


    Wir haben auch mehrere Kunden, mit einer IQueue und uns ist das nie aufgefallen.


    Mir ist aber eine Idee gekommen.


    Soweit ich weiss gibt es einen Parameter "Max-Forwards" im SIP. Dieser soll verhindern dass ein SIP-Ruf in einem Unendlichen Loop stecken bleibt.


    Nun sagen wir, wir haben ein Max-Forwards von 20.


    Der Anruf kommt rein, und wird ans Modul weitergeleitet (Max-Forwards = 19)
    Das Modul nimmt den Anruf an, und Parkiert ihn (Max-Forwards =18)
    Das Modul nimmt den Anruf wieder entgegen (Max-Forwards=17)
    ...


    Oder im Beispiel der IQueue
    Der Anruf kommt rein, wird zur IQueue weitergeleitet (Max-Forwards = 10)
    Der Anruf wird in der Warteschlange Pakiert (Max-Forwards = 9)
    Der Anruf wird zurückgeholt, um eine Positionsansage zu machen (Max-Forwards = 8)
    ...


    Eventuell lässt sich das gleiche Ergebnis auch provozieren, indem man einen Anruf 20 mal Transferiert, wen dem so ist.


    Max-Forwards https://tools.ietf.org/html/rfc3261#section-8.1.1.6


    Es sagt zwar


    Zitat

    consists of an
    integer that is decremented by one at each hop. If the Max-Forwards
    value reaches 0 before the request reaches its destination, it will
    be rejected with a 483(Too Many Hops) error response.


    Aber es könnte sich ja trotzdem auf den Asterisk-Internen Dialplan auswirken?


    MfG


    Fabian

  • @ Ulf,

    Die von Dir gezeigte Herangehensweise ist aber tatsächlich komplett anders, als ein von mir genutzter Ansatz.


    Du meinst mein Modul, ja das war ja zum Fehler provozieren.



    Spannend bei Deinem Ansatz: es ist auf den ersten Blick gar kein "Fehler" erkennbar - aber konsequent wird an immer gleicher Stelle abgebrochen und das bei einem Banalsriptablauf ... :confused:


    Ja und ich denke das Problem liegt auch nicht im Modul, sondern es ist hier was generelles im Asterisk.


    @ Fabian,



    Das ist ein sehr guter Punkt an den ich noch gar nicht gedacht habe.
    Kann es sein das deine Kunden einfach nicht merken (aufgrund der Menge) wenn mal ein Gespräch raus fliegt?
    Bzw. wenn es angenommen und dann nicht mehr verbunden wird würde ja auch nichts passieren.




    Eventuell lässt sich das gleiche Ergebnis auch provozieren, indem man einen Anruf 20 mal Transferiert, wen dem so ist.


    Was auf jedenfall geht, wenn Du im Callmanager (WebGUI) einen Anruf auf halten setzt und wieder annimmst, beim neunten mal ist er weg.


    Was mich interessieren würde, ist das im UCC Client auch so, kann das mal jemand testen?


    @ Wolfgang,


    steht im Call Routing Log so was hier: "Max routing count reached for channel" ?


    Tatsächlich gibt es zwei Einträge in der Log, vermutlich kommt das aber eher von einer falschen Gruppenanmeldung und im "Kreis klingeln".
    Wäre das immer das Problem müsste es viel öfter auftreten.


    Code
    [root@tel starface]# grep -r "Max routing count reached for channel" *
    error.log.5:[2017-07-20 09:59:39,324] ERROR de.starface.ch.routing.RoutingLogic Max routing count reached for channel SIP/XXXX[...]
    error.log.6:[2017-05-23 14:46:02,614] ERROR de.starface.ch.routing.RoutingLogic Max routing count reached for channel SIP/XXXX[...]


    Bis jetzt wissen wir nur das irgendetwas beim Parken schief geht.


  • Was mich interessieren würde, ist das im UCC Client auch so, kann das mal jemand testen?


    Könnte jemand mit dem UCC Client mal versuchen 9x ein Gespräch auf halten zu setzten und wieder anzunehmen?
    Fliegt es dann auch raus?

  • 9x Halten und Aktivieren geht. Beim 10. Halten fliegt der Call weg.


    Im Call Routing Log steht dann:


    [2018-09-12 14:22:22,650] ERROR [AGI 1-SIP/1005.DE410IP-0000001a] RoutingLogic Max routing count reached for channel SIP/1005.DE410IP-0000001a:1536754941.73



    Dahinter steckt eine Logik zur Vermeidung von Endlos-Schleifen im Call Routing. Allerdings muss ein ordentlicher Connect (also ein erfolgreiches Aktivieren eines gehaltenen Anrufs) den entsprechenden Zähler zurücksetzen.




    Gruß Wolfgang

  • Danke fürs testen Wolfgang, ok das macht Sinn.
    Bei den Gesprächen die wir verloren haben stand das jedoch nicht im Log, das Problem muss daher noch ein anderes sein.


    Wenigstens Callmanager wäre damit gelöst.

  • @ Starface,


    ich bin sehr entäuscht das hier kein Bugfix entsteht, ehrlich gesagt fühle ich mich nicht mehr ernst genommen.
    Wo ist die dynamische Starface welche wir vor 10 Jahren kennen gelernt haben?


    Nicht mal so einfach Dinge wie Leitung zuklappen [1] werden in 2 Jahren korrigiert.


    [1] https://support.starface.de/fo…-3-Beta&p=39237#post39237

  • Hallo,


    ich kann verstehen, dass man nicht zufrieden ist, wenn einfache Dinge nicht geändert werden, aber zum einen gibt es bei weitem dringendere Dinge, die wir lösen müssen und zum anderen hat Beka damals schon gesagt, dass gar nicht klar ist, ob wir das wieder anpassen werden. ("Das Thema ist bei uns vermerkt, aber nicht mit hoher Priorität, weil es nur die Systeme mit außergewöhnlich vielen Leitungen betrifft. Ob wir es umsetzen, ist noch nicht klar.")


  • ich kann verstehen, dass man nicht zufrieden ist, wenn einfache Dinge nicht geändert werden, aber zum einen gibt es bei weitem dringendere Dinge, die wir lösen müssen


    Falls das wegen den Leitungen gemeint ist, macht euch nicht lächerlich.
    Das sind ein, zwei Zeilen Code das die Voreinstellung wieder zu ist, irgendwann hatte auch mal jemand Zeit dieses nervige Thema zu ändern. Und das schafft man in zwei Jahren nicht?


    Was ist mit dem Bug hier? Hier geht auch nichts vorwärts außer wir sind dran.


    Edit: Ich hab Verständnis wenn Dinge länger dauern können, auch weil sie sich als viel komplexer herausstellen als gedacht, ich kenne das selber gut.
    Aber in letzter Zeit dauern viele Dinge einfach zu lang.

    Grüße
    slu


    ---
    Ich bin kein Starface Partner - zufriedener Starface Anwender seit Anfang 2008.

    Meine Module: Einfache Community Blacklist

    Einmal editiert, zuletzt von slu () aus folgendem Grund: Edit hinzu.

  • Hey slu,


    habe da auch noch ein Thema mit der iQueue bei der die Einstellungen(max-verweildauert & Abwurfplatz) einfach ignoriert werden.


    Liegt jetzt auch seit 2 Monaten in der Entwicklung und der Kunde regt sich natürlich total auf...


    Dir trotzdem Viel Glück bei der Lösung. Ich glaube das kann auch lange dauern.. Denn falls wirklich ein Counter wie max-forwards der Auslöser ist kann er ja auch nicht einfach hoch gesetzt werden... Der hat ja schon sein berechtigten Sinn.

    MfG


    Schulz

Jetzt mitmachen!

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