Posts by Björn G.

    Hallo Fabian,


    danke für deine Rückmeldung. Ich hab heute den Support hinzugezogen. Und wir sind auch so verblieben, daß wir einen Dump zur Analyse benötigen.

    Bei uns im Haus sind nur Windows UCCs im Einsatz für die Support-Agenten, und die betrifft es idR. auch, da hier das meiste Anrufaufkommen ist.


    Nun muss ich nur rausfinden wieso der Dump abbricht... :/

    Ich starte ihn:
    pasted-from-clipboard.png

    Und ein paar Sekunden später kommt der hier:

    pasted-from-clipboard.png


    Ich hake mal den SIP/RTP und schaue ob der läuft.

    Grüße,
    Björn

    Moin zusammen,

    nachdem unser Netzwerk und unsere Cloud-Instanz über Monate selbst und fremdgesteuert fehleranfällig war, läuft sie nun seit Juni (knock on wood) rock-solid.
    So wie es immer sein sollte, und bitteschön auch so bleibt.

    Wir haben immer wieder 0Sek. Inbounds, die sehr sporadisch auftreten.

    Bei allen 0Sek. Calls die ich untersucht habe, tauchen in dem PBX (full) die Zeilen auf:


    Code
    VERBOSE[1766768][C-000019f6] pbx.c: Executing [h@calling:1] NoOp("SIP/XYZ", "HC 16") in new stack
    VERBOSE[1766768][C-000019f6] pbx.c: Executing [h@calling:2] Goto("SIP/XYZ", "_exit_,0") in new stack

    Der HC 16 sagt ja 'Normal Clearing'. Also sieht das aus, daß die Gegenstelle den Ruf prompt beendet.

    Und im Support Log:

    Code
    [ 4711 ] Hangup Cause: NOTDEFINED


    Heute, zum Zeitpunkt 125 Calls, 7 davon mit 0Sek., einer von den 7 vom Handy (also eher nicht relevant). Damit haben wir ein inbound-Fehler von ~5,5%

    Ist das viel, ist das okay, woran kann das liegen?

    pasted-from-clipboard.png


    Für Rückmeldung jeglicher Art bin ich dankbar.

    Grüße,
    Björn

    Jo, löschen und neu anlegen, hilft nicht. Wir haben mindestens 5 Agents mit Win-UCC, bei denen stumpf '3' angezeigt wird, unabhängig davon ob und wieviele Voicemails tatsächlich vorliegen...


    Server in der CLOUD: 7.2.1.2
    UCC-Clients: 7.2.0.153

    Jabra Direct zu installieren, wäre auch mein Tipp gewesen.
    Alternativ mal jedes Headset an einer eigenen USB-Buchse am Gerät betreiben, nicht daß Windows die Treiber durcheinanderwurschtelt.

    Beispiel:
    Standort 1.: Dongle oder Headset in USB-Busche links am Gerät, oder Dock.
    Standort 2.: Dongle oder Headset in USB-Buchse rechts am Gerät, oder im Dock.

    Klingt komisch? Könnte aber klappen.

    Ansonsten der Klassiker gegen Leck-Ströme, Geräte/Docking, über Nacht mal stromlos lassen. Beim Lappie mit verklebten Akku geht das ja leider nicht mehr.

    Dachte ich auch gerade. Unser lokaler Provider sagt er hat nichts am Netz geschraubt und es gibt keine Störungen. Latenz hat sich in Richtung RZ/Cloud aber um ~14:55 Uhr geändert, und Paketloss ist auch nicht zu verachten:


    Hab grad beim Support die Störung [Call#7292211] auf gemacht. ;)

    Moin zusammen, wir haben hier 3 Agents deren UCC mit einem Crash-Dump abgestürzt sind. Bei 2 PCs hat danach Garnichts mehr reagiert und die PCs mussten hart resettet werden.

    Hat das sonst noch jemand?
    Ist der Fehler bei SF bekannt?

    Windows PCs, Version:
    Microsoft Windows 10 Pro, 64-bit (build 19044)

    System:

    Modellspacer.gif LENOVO 11EV001LGE
    CPUspacer.gif Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz 2,90 GHz, 2048 KB Level-2-Cache
    BIOSspacer.gif M2TKT4DA LENOVO - 14D0
    RAMspacer.gif 16.384 MB RAM
    SSDspacer.gif SKHynix_HFS512GDE9X081N 476,94GB SCSI



    Auszug aus dem Crash-Dump

    Grüße,
    Björn

    Heute Morgen wieder.

    Eingehende Anrufe waren plötzlich weg, die UCC hatten angeblich eine aktive Verbindung zur SF-Cloud. Wieder diese Einträge.

    Was sagen mir diese Einträge? Die Anlage bucht die Clients neu ein? Aber warum fast gleichzeitig?
    Wie kann man das entzerren, damit das nicht bei allen annähernd gleichzeitig passiert?


    [2022-05-17 07:04:09,501] VERBOSE[67454] chan_sip.c: Unregistered SIP 'Dieter.WinClient'

    [2022-05-17 07:04:09,524] VERBOSE[67454] chan_sip.c: Registered SIP 'Dieter.WinClient' at 10.0.29.1:34621

    [2022-05-17 07:04:17,372] VERBOSE[67454] chan_sip.c: Unregistered SIP 'Sonja.WinClient'

    [2022-05-17 07:04:17,395] VERBOSE[67454] chan_sip.c: Registered SIP 'Sonja.WinClient' at 10.0.29.1:34621

    [2022-05-17 07:04:19,771] VERBOSE[67454] chan_sip.c: Unregistered SIP 'Frank.WinClient'

    [2022-05-17 07:04:19,792] VERBOSE[67454] chan_sip.c: Registered SIP 'Frank.WinClient' at 10.0.29.1:34621

    [2022-05-17 07:04:28,588] VERBOSE[67454] chan_sip.c: Unregistered SIP 'Klaus.WinClient'

    [2022-05-17 07:04:28,610] VERBOSE[67454] chan_sip.c: Registered SIP 'Klaus.WinClient' at 10.0.29.1:34621

    Frohes schaffen und Grüße,
    Björn

    Moin Fabian.

    Vielen Dank für deine Antwort. Ist tatsächlich genau das was ich suche.
    Denn die Oberfläche der Cloud bietet keine Möglichkeit das Openfire-Log schicken zu lassen.

    Ich schaue mir dein Modul mal genauer an und wäge ab ob ich das aktiviere, selber baue, oder lieber -aus Unerfahrenheit- die Finger davon lasse.

    Prima, daß Du deine Expertise und Arbeit hier zur Verfügung stellst!

    Grüße,
    Björn

    Moin zusammen,


    wir haben das Phänomen, daß ab und zu (also nicht immer, das wäre ja zu leicht) UCCs nicht telefonieren können, Anrufe nicht entgegen nehmen können, oder nicht gehört werden, Anrufe einfach wegbrechen, das ganze Spektrum an Fehlerbildern.
    Ich suche da an diversen Baustellen im Netz, u.a. läuft hier ein WAN-Loadbalancer. Keine gute Idee, ich weiß, das Konstrukt wird bald geändert. Nun schaue ich mir in Ruhe die ganzen Logs an, ohne groß Erfahrung oder Wissen zu haben...

    Wenn ich im PBX-Log sowas sehe, dann sagt mir das doch eigentlich, daß die UCCs alle unter derselben IP und Port eingebucht werden, richtig? Das kann doch so nicht funktionieren, aber wie und wo abstellen. Die NAT-Vorhaltezeit am LANCOM ist schon auf 61Sek. eingestellt und das TCP und UDP Aging angepasst. Aber irgendwas passt da noch nicht...

    Liege ich richtig, daß es solche Logeintrage bei richtigem NATing eigentlich nicht geben sollte?
    Oder muss ich am lokalen Netzwerk-Router ins NATing schauen um zu prüfen ob er das intern richtig zuweist?


    [2022-05-03 08:23:18,332] VERBOSE[1926964] chan_sip.c: Unregistered SIP 'Dieter.WinClient'

    [2022-05-03 08:23:18,384] VERBOSE[1926964] chan_sip.c: Registered SIP 'Dieter.WinClient' at 10.x.y.1:35185

    [2022-05-03 08:23:18,658] VERBOSE[1926964] chan_sip.c: Unregistered SIP 'Sonja.WinClient'

    [2022-05-03 08:23:18,777] VERBOSE[1926964] chan_sip.c: Registered SIP 'Sonja.WinClient' at 10.x.y.1:35185

    [2022-05-03 08:23:21,710] VERBOSE[1926964] chan_sip.c: Unregistered SIP 'Klaus.WinClient'

    [2022-05-03 08:23:21,763] VERBOSE[1926964] chan_sip.c: Registered SIP 'Klaus.WinClient' at 10.x.y.1:35185

    [2022-05-03 08:23:23,837] VERBOSE[1926964] chan_sip.c: Unregistered SIP 'Ben.WinClient'

    [2022-05-03 08:23:23,883] VERBOSE[1926964] chan_sip.c: Registered SIP 'Ben.WinClient' at 10.x.y.1:35185


    Grüße,
    Björn