Posts by Björn G.

Okay, danke. Ich starte dann heute Nacht mal die Cloud neu durch.

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

Normal ist das tatsächlich nicht mehr, das war gestern Nachmittag los...

pasted-from-clipboard.png

Und meine bisherigen Indizien oder Such-Strings bringen keine Treffer. Sieht so aus, als wenn technisch -laut PBx/full- Alles bestens sei. Nur die paar UCC Abmeldungen zu sehen...

pasted-from-clipboard.png

Laufzeit, Bandbreite und Jitter zum RZ des CLOUD-RZ von netcup/Starface. Alles nur in Momentaufnahme. Ist ein 'custom-ierter' View vom Ookla. (https://www.speedtest.net/de)

Es wird deine WAN als Source und die Destination von Starface verwendet.

Geht wieder

pasted-from-clipboard.png

http://starface.speedtestcustom.com/

pasted-from-clipboard.png

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:

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:

[ 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.

Wie habe ich das zu verstehen? Ich hab bisher keine Möglichkeit in der Admin-Oberfläche gefunden explizit einen DNS anzugeben...

Quote from Anastasia Raevski

....bei Clouds ohne dedizierte IP-Adresse.

Das Routing wurde die letzten Tage scheinbar öfters geändert. (Die letzten 8 Tage...)
pasted-from-clipboard.png

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:

Modell LENOVO 11EV001LGE
CPU Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz 2,90 GHz, 2048 KB Level-2-Cache
BIOS M2TKT4DA LENOVO - 14D0
RAM 16.384 MB RAM
SSD SKHynix_HFS512GDE9X081N 476,94GB SCSI

Auszug aus dem Crash-Dump

22-07-07 09:29:03.317 |   1 | ERROR |          | UcClient.FormMain    | HandleUccEvent                 | OnUccEvent | EXCEPTION:


System.ComponentModel.Win32Exception (0x80004005): Fehler beim Erstellen des Fensterhandles.
   bei System.Windows.Forms.NativeWindow.CreateHandle(CreateParams cp)
   bei System.Windows.Forms.Control.CreateHandle()
   bei System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   bei System.Windows.Forms.Control.CreateControl()
   bei System.Windows.Forms.Control.ControlCollection.Add(Control value)
   bei System.Windows.Forms.TableLayoutControlCollection.Add(Control control, Int32 column, Int32 row)
   bei UcClient.WidgetIQueue.DissociateCalls(QueueCall queueCall)
   bei UcClient.WidgetIQueue.HandleQueueCall(QueueCall queueCall)
   bei UcClient.FormMain.HandleUccEvent(UccEventBase uccEvent)


22-07-07 09:29:03.699 |  63 | DEBUG |          | UccAPI.UccIQueue     | UpdateQueueCall                | Information of the queue call(73fa8fff-401f-49c8-a015-1310104a918b) was changed. 
22-07-07 09:29:03.759 |   7 | DEBUG |          | UccAPI.UccIQueue     | UpdateQueueCall                | Information of the queue call(6aa57492-c84b-45ed-97ce-dd2456db5d23) was changed. 
22-07-07 09:29:03.921 |  59 | DEBUG |          | UccAPI.UccIQueue     | UpdateQueueCall                | Information of the queue call(73fa8fff-401f-49c8-a015-1310104a918b) was changed. 
22-07-07 09:29:03.969 |   4 | DEBUG |          | UccAPI.UccIQueue     | UpdateQueueCall                | Information of the queue call(6aa57492-c84b-45ed-97ce-dd2456db5d23) was changed. 
22-07-07 09:29:04.295 |   1 | ERROR |          | UcClient.UccSentryRe | ReportCrashDump                | CrashDumpID: 2761dfc96ed044fc81677fdce1376459 
22-07-07 09:29:04.308 |   1 | TRACE |          | UcClient.UccSentryRe | SessionEnd                     | SessionEnd 00:26:38.0714489 
22-07-07 09:29:04.308 |   1 | FATAL |          | UcClient.Program     | Write                          | Caught unhandled exception:  | EXCEPTION:


System.ComponentModel.Win32Exception (0x80004005): Fehler beim Erstellen des Fensterhandles.
   bei System.Windows.Forms.NativeWindow.CreateHandle(CreateParams cp)
   bei System.Windows.Forms.Control.CreateHandle()
   bei System.Windows.Forms.Control.get_Handle()
   bei System.Windows.Forms.Control.CreateGraphicsInternal()
   bei System.Windows.Forms.ThreadExceptionDialog..ctor(Exception t)
   bei System.Windows.Forms.Application.ThreadContext.OnThreadException(Exception t)
   bei System.Windows.Forms.Control.WndProcException(Exception e)
   bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   bei System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
   bei System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
   bei System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   bei System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   bei UcClient.Program.Main(String[] args)

22-07-07 09:29:04.308 |   1 | FATAL |          | UcClient.Program     | DumpUnhandledException         | Write memory dump to file C:/Users/b.juergens/AppData/Local/Temp/STARFACE GmbH/App/logs\STARFACE_2022-7-7_9-29-4-309.mdmp. Full dump: False 
22-07-07 09:29:05.006 |   1 | FATAL |          | UcClient.Program     | DumpUnhandledException         | Written memory dump to file C:/Users/b.juergens/AppData/Local/Temp/STARFACE GmbH/App/logs\STARFACE_2022-7-7_9-29-4-309.mdmp 
22-07-07 09:29:05.006 |   1 |  INFO |          | UccAPI.UccSupportUti | Write                          | ---------- 

Grüße,
Björn

Irgendwas mache ich falsch. Funktioniert das Modul mit der 7.2.0.5 noch?
Denn:

pasted-from-clipboard.png

Beim Testen der Verbindung holt er sich auch nur den Token, aber keine Version des Moduls oder der Starface wird angezeigt.
Server wurde nach aktivieren des Moduls und der Instanz neu gestartet.

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

Wir nutzen Starface als Cloud, daher meine Frage: In welchem Log schreibt das Openfire rein? Ich stehe gerade auf dem Schlauch und kann dazu nichts finden in der Log-Übersicht der Cloud.

Achja, das sehe ich auch immer wieder in den Support-Paketen die die User mir schicken:

User-Agent: STARFACE PBX

X-Asterisk-HangupCause: Network out of order

X-Asterisk-HangupCauseCode: 38

GEFUNDEN, da gibts nen Mapping zu den Codes:

https://wiki.asterisk.org/wiki…AST/Hangup+Cause+Mappings

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

checkmk 2.0: https://checkmk.com/de
Ist Netsaint/Nagios basiert. Schnell eingerichtet und durch die regeln angenehm fein zu justieren.

Ist easy auf Debian zu installieren.