Anleitungen und Fehlerbehebung verwandte FAQs

1 Inhalt

2 Beidhändige Rückhand: Einleitung

3 Häufige Probleme

3.1 Probleme mit der Netzwerkverbindung

3.1.1 Verbindung fehlgeschlagen

3.1.2 DNS-Fehler

3.1.3 Ungültiger Pfad

3.1.4 Nicht autorisiert

3.1.5 Stream gestoppt

3.1.6 Verbindung beendet

3.1.7 Ende des Streams

3.1.8 Ungültige Verbindung

3.2 Dekodierungsprobleme

3.2.1 Nicht unterstützter Stream

3.2.2 Ungültiger Stream

3.3 Stottern und Videobeschädigung

4 Erweiterte Fehlerbehebung

4.1 Protokollierung aktivieren

4.2 Protokolle abrufen

4.3 Paketverlust und Jitter erkennen

4.4 IGMP-Multicast-Probleme

5 Anhänge

5.1 Protokollierungsarten

5.1.1 SQX-Protokollierung

5.1.2 GStreamer-Protokollierung

5.1.3 Pipeline-Protokollierung

5.1.4 Paketprotokollierung

2 Beidhändige Rückhand: Einleitung

Dieses Dokument beschreibt die unterstützungsorientierte Funktionalität, die in der ActiveSXQ-Karte implementiert wurde, und den Prozess, der dabei erfolgt Datapath Anschließend werden wir mithilfe dieser Funktionen alle Probleme, die bei der Bereitstellung von ActiveSQX auftreten können, schnell untersuchen und beheben.

Das Dokument beschreibt die Schritte, die unternommen werden sollten, wenn eine IP-Stream-Quelle nicht mit der ActiveSQX-Karte funktioniert. Ein IP-Stream kann eine Vielzahl von Hardware- und Softwarekomponenten durchlaufen, und es gibt ebenso viele Gründe, warum der Stream möglicherweise nicht funktioniert. Das Dokument behandelt die potenziellen Probleme in der Reihenfolge von den häufigsten bis zu den seltensten. Die häufigen Probleme könnten vom Endbenutzer oder vom First-Line-Support ohne großen Aufwand diagnostiziert werden, einige der weniger häufigen Probleme müssen jedoch eskaliert werden Datapath für weitere Untersuchungen und die damit verbundenen Prozesse werden ebenfalls beschrieben.

3 Häufige Probleme

Wenn zum ersten Mal ein Fenster zur Anzeige eines IP-Streams geöffnet wird, wird „Verbinden“ im Fenster angezeigt. Dies zeigt an, dass die ActiveSQX-Karte versucht, eine Verbindung zur IP-Stream-Quelle herzustellen. Dies kann je nach Qualität des Netzwerks und der Quelle zwischen einem Bruchteil einer Sekunde und einer halben Minute dauern.

Bei Netzwerkproblemen wird möglicherweise sofort ein Fehler im Fenster angezeigt oder die Software kann nach etwa 30 Sekunden abbrechen und dann eine Fehlermeldung im Fenster anzeigen.

Die verschiedenen Arten von Netzwerkproblemen werden in Abschnitt 3.1 beschrieben. Vorausgesetzt, die Netzwerkverbindung kann korrekt hergestellt werden, können verschiedene Probleme bei der Dekodierung auftreten, z. B. beim Versuch, einen Stream zu dekodieren, der ein Kodierungsformat oder eine bestimmte Funktion dieses Formats verwendet, die ActiveSQX nicht unterstützt. Diese werden in Abschnitt 3.2 beschrieben.

3.1 Probleme mit der Netzwerkverbindung

Bei Problemen mit dem Netzwerk kann einer der folgenden Fehler auftreten:

3.1.1 Verbindung fehlgeschlagen

Das bedeutet, dass ActiveSQX keine Verbindung mit der Quell-IP-Adresse und dem Quell-Port herstellen konnte. In einigen Fällen kann es sein, dass die Quelle die Verbindung aufgrund eines ungültigen Benutzernamens und Passworts abgelehnt hat (siehe Abschnitt 3.1.4) oder dass die Quell-IP die maximale Anzahl unterstützter Verbindungen erreicht hat.

3.1.1.1 Physische Verbindung prüfen

Stellen Sie sicher, dass ein Ethernet-Kabel mit dem ActiveSQX verbunden ist und sich in einem Netzwerk befindet, das physischen Zugriff auf die IP-Adresse der Quelle hat.

3.1.1.2 IP-Adresse prüfen

Wenn DHCP verwendet wird, stellen Sie sicher, dass ActiveSQX eine IP-Adresse erhalten hat. Überprüfen Sie dies, indem Sie den Geräte-Manager öffnen und unter „Sound-, Video- und Gamecontroller“ auf die ActiveSQX-Karte doppelklicken. Gehen Sie zur Registerkarte „Konfiguration“ und suchen Sie im ausgegrauten IP-Adressfeld nach einer IP-Adresse, wie in Abbildung 1 dargestellt. Wenn die Registerkarte „Konfiguration“ nicht vorhanden ist, konnte ActiveSQX keine Verbindung mit dem Host-Computer herstellen. Wenn dies der Fall ist, versuchen Sie, die Karte herunterzufahren und wieder einzuschalten. Wenn die Registerkarte immer noch nicht angezeigt wird, ist entweder die Karte fehlerhaft oder wurde in einen nicht unterstützten Host-Computer eingelegt.

Abbildung 1 Konfiguration des ActiveSQX-Gerätemanagers

Das IP-Adressfeld wird nur aktualisiert, wenn das Dialogfeld zum ersten Mal geöffnet wird. Wenn also anschließend ein Ethernet-Kabel an ActiveSQX angeschlossen wird, muss das Dialogfeld geschlossen und erneut geöffnet werden, damit es aktualisiert wird. Wenn im Dialogfeld keine IP-Adresse angezeigt wird, überprüfen Sie, ob der DHCP-Server ordnungsgemäß ausgeführt wird. Verwenden Sie bei Bedarf einen Paket-Sniffer wie Wireshark auf einem anderen Computer, der mit demselben Netzwerk verbunden ist, um zu überprüfen, ob DHCP-Pakete übertragen werden. Wenn der DHCP-Server nicht ordnungsgemäß funktioniert, versuchen Sie stattdessen, eine statische IP-Adresse zuzuweisen. Wenn jedoch eine statische IP-Adresse zugewiesen wird, achten Sie darauf, keine Adresse innerhalb des für DHCP reservierten Bereichs auszuwählen, um IP-Adresskonflikte zu vermeiden.

3.1.1.3 IP-Adressen anpingen

Sobald der ActiveSQX eine IP-Adresse hat, überprüfen Sie, ob er auf Ping-Anfragen von einem anderen Computer im Netzwerk reagiert, indem Sie „ping xxxx“ über eine Eingabeaufforderung eingeben und dabei xxxx durch die IP-Adresse des ActiveSQX ersetzen. Stellen Sie außerdem sicher, dass die Quelle auf Ping-Anfragen an ihre IP-Adresse reagiert. Sofern die Ping-Anfragen erfolgreich sind, überprüfen Sie, ob die für die Quelladresse eingegebene Portnummer korrekt ist. Stellen Sie außerdem mithilfe eines Software-Mediaplayers wie VLC sicher, dass der Stream von einem anderen Computer im selben Netzwerk aus zugänglich ist.

3.1.2 DNS-Fehler

Wenn für die IP-Quelle ein Domänenname und nicht eine IP-Adresse eingegeben wird und diese nicht aufgelöst werden konnte, wird dieser Fehler angezeigt. Überprüfen Sie, ob der Domänenname korrekt ist und mit dem Ping-Befehl darauf zugegriffen werden kann. Andernfalls kann es daran liegen, dass ActiveSQX keine Verbindung zum Domänennamenserver herstellen kann. Die Adresse von 1 oder 2 DNS-Servern kann explizit über die ActiveSQX-Eigenschaftenseite im Geräte-Manager angegeben werden, wenn der DNS nicht automatisch über DHCP eingerichtet werden kann.

3.1.3 Ungültiger Pfad

Dieser Fehler tritt auf, wenn eine Verbindung zur IP-Quelle hergestellt wurde, die Quelle jedoch den angegebenen Pfad ablehnt. Überprüfen Sie den Pfad in Wall Control, indem Sie den Dialog „IP-Kamerakonfiguration“ öffnen und die Registerkarte „Kameramodelle“ auswählen. Wählen Sie die entsprechenden cameraKlicken Sie auf „Ändern…“ und überprüfen Sie, ob der Pfad korrekt ist.

3.1.4 Nicht autorisiert

Dieser Fehler zeigt an, dass die IP-Quelle die Verbindung abgelehnt hat. Dies kann an einem ungültigen Benutzernamen oder Passwort liegen. Überprüfen Sie den Benutzernamen und das Passwort in Wall Control, indem Sie den Dialog „IP-Kamerakonfiguration“ öffnen und die Registerkarte „Kameras“ auswählen. Wählen Sie die entsprechende cameraKlicken Sie auf „Ändern…“, wählen Sie das Optionsfeld „Benutzername“ aus und geben Sie die Anmeldedaten ein.

3.1.5 Stream gestoppt

Dieser Fehler weist darauf hin, dass in der letzten Sekunde keine Videobilder dekodiert wurden. Dies kann auf einen vorübergehenden Netzwerkfehler zurückzuführen sein, z. B. wenn ein Kabel abgezogen wurde, und kann wiederhergestellt werden, sofern die Netzwerkverbindung wiederhergestellt wird, bevor die Verbindung abbricht. Dies kann auch auftreten, wenn die maximale Decodierungskapazität des ActiveSQX überschritten wird. Die Grenzwerte finden Sie im Datenblatt.

3.1.6 Verbindung beendet

Dieser Fehler tritt in Situationen auf, in denen die Verbindung über einen längeren Zeitraum (z. B. etwa 30 Sekunden) unterbrochen wird. Dies kann verschiedene Gründe haben:

• Ein Kabel wurde irgendwo zwischen der Quelle und dem ActiveSQX getrennt
• Die Quelle könnte beispielsweise das Streaming gestoppt haben, wenn sie ausgeschaltet war
• Wenn es sich bei der Quelle um Multicast handelte, liegt möglicherweise eine Fehlkonfiguration in den IGMP-Netzwerkeinstellungen vor
  die Schalter (siehe Abschnitt 4.3 für weitere Einzelheiten)

3.1.7 Ende des Streams

Dies ist eigentlich kein Fehler, sondern zeigt lediglich an, dass der Quell-IP-Stream beendet wurde. Normalerweise wird diese Meldung nur angezeigt, wenn die Quelle eine Videodatei mit fester Länge und kein endloser Livestream war.

3.1.8 Ungültige Verbindung

Dieser Fehler weist darauf hin, dass ein allgemeiner Netzwerkfehler aufgetreten ist. Weitere Untersuchungen sind erforderlich, wie in Abschnitt 4 beschrieben.

3.2 Dekodierungsprobleme

Wenn beim Dekodieren des Quell-IP-Streams Probleme auftreten, wird möglicherweise einer der folgenden Fehler angezeigt:

3.2.1 Nicht unterstützter Stream

Dieser Fehler weist normalerweise darauf hin, dass das Kodierungsformat des Quell-IP-Streams nicht unterstützt wird, oder es kann auch ein Hinweis auf ein nicht unterstütztes Transportprotokoll sein. Eine Liste der unterstützten Formate finden Sie im ActiveSQX-Datenblatt. In einigen Fällen kann das Problem möglicherweise behoben werden, indem der Quell-IP-Stream in einem kompatiblen Format konfiguriert wird. Wenn das Codierungsformat der Quelle unbekannt ist, kann es mit einem Software-Mediaplayer wie VLC überprüft werden.

3.2.2 Ungültiger Stream

Dieser Fehler weist darauf hin, dass ein generischer Stream-Fehler aufgetreten ist. Weitere Untersuchungen sind erforderlich, wie in Abschnitt 4 beschrieben.

3.3 Stottern und Videobeschädigung

In einigen Fällen können beim ersten Anschließen mehrere grün gefärbte Rahmen sichtbar sein, die sich nach einiger Zeit von selbst korrigieren. Bei H264-kodiertem Video liegt dies daran, dass beim ersten Verbindungsaufbau kein I-Frame von der IP-Quelle empfangen wurde. Die IP-Quelle sollte bei der Verbindung einen I-Frame senden, aber nicht alle IP-Quellen tun dies. Leider kann ActiveSQX nichts dagegen tun.

Ein weiteres häufiges Problem bei IP-Streams ist das Auftreten von Videoruckeln und/oder Dekodierungsartefakten. Da die Decodierung von Frames oft davon abhängt, dass die Frames zuvor erfolgreich decodiert wurden, reagieren IP-Streams sehr empfindlich auf Störungen, was sich häufig in einer Videobeschädigung äußert.

Decodierungsartefakte werden normalerweise durch Netzwerkpaketverluste verursacht. Um dies zu bestätigen, versuchen Sie am besten, die Route von der Quelle zum ActiveSQX so kurz wie möglich zu gestalten. Wenn physischer Zugriff auf das Netzwerk verfügbar ist, versuchen Sie, die Quelle und ActiveSQX direkt mit demselben Switch zu verbinden und alle anderen nicht benötigten Ports zu trennen, um zu sehen, ob die Probleme weiterhin bestehen. Möglicherweise ist auch der Schalter oder die Verkabelung fehlerhaft. Versuchen Sie es nach Möglichkeit mit mehreren verschiedenen Schaltern und Kabeln. Wenn dies immer noch fehlschlägt, könnte die Quelle fehlerhaft sein. Versuchen Sie es mit anderen IP-Quellen. Wenn kein physischer Zugriff auf das Netzwerk möglich ist, versuchen Sie, den Paketverlust mithilfe der in Abschnitt 4 beschriebenen Protokollierungstechniken zu messen.

Stotterndes Video kann auch durch Netzwerkpaketverlust verursacht werden, ist aber normalerweise auch mit Dekodierungsartefakten verbunden. Wenn Videoruckeln ohne Artefakte auftritt, kann dies daran liegen, dass Pakete unterschiedlich lange brauchen, um vom Quell-IP-Stream zum ActiveSQX übertragen zu werden. Der ActiveSQX speichert Pakete standardmäßig 200 Millisekunden lang zwischen, bevor er sie dekodiert. Dies ermöglicht eine reibungslose Wiedergabe, auch wenn Pakete nicht mit einer gleichmäßigen Geschwindigkeit empfangen werden, vorausgesetzt, der Unterschied in der Übertragungszeit zwischen dem langsamsten und dem schnellsten Paket überschreitet 200 ms nicht. Dieser Wert kann in Wall Control konfiguriert werden, indem Sie den Dialog „IP-Kamerakonfiguration“ öffnen und die Option cameraKlicken Sie auf „Ändern…“, dann auf „Erweitert“ und ändern Sie den Wert für „Cache“. Erhöhen Sie den Wert, bis das Ruckeln verschwindet. Beachten Sie jedoch, dass eine Erhöhung dieses Werts zu einer Verzögerung zwischen dem Live-Signal und dem angezeigten Video führt. Falls das Problem durch Ändern des Cache-Werts nicht behoben werden kann, liegt die Ursache möglicherweise in der IP-Quelle. Versuchen Sie, dieselbe Quelle mit einem Mediaplayer wie VLC zu dekodieren, um zu prüfen, ob das Problem dort ebenfalls auftritt.

4 Erweiterte Fehlerbehebung

In Fällen, in denen das Problem anhand von Abschnitt 3 nicht identifiziert werden kann, muss die integrierte Protokollierungsfunktion von ActiveSQX genutzt werden. Standardmäßig ist die Protokollierung aus Leistungs-, Haltbarkeits- und Sicherheitsgründen deaktiviert, ist jedoch für die Fehlerbehebung bei komplizierten Problemen von unschätzbarem Wert.

Die Protokollierung sollte aktiviert sein und dann sollte das Problem reproduziert werden, indem der problematische IP-Stream geöffnet wird (oder alle erforderlichen Schritte ausgeführt werden). Die Protokolldateien können dann analysiert werden, um die Ursache des Problems zu ermitteln, oder an zurückgesendet werden Datapath zur weiteren Analyse, falls erforderlich.

4.1 Protokollierung aktivieren

Die Protokollierung kann mit dem Befehlszeilentool cmd183.exe über eine Eingabeaufforderung aktiviert werden. Als Ausgangspunkt sollten SQX-Protokollierungswarnungen und -Fehler mit GStreamer-INFO-Level-Protokollierung und Pipeline-Dump über die folgende Befehlszeile aktiviert werden:

cmd183.exe Setlog-Datei –s 2 –g 4 –p

Diese Protokolle enthalten keine vertraulichen Informationen und sind recht umfangreich. Weitere Einzelheiten zu den verschiedenen Protokollierungsarten und zur Verwendung des cmd183-Tools finden Sie in Abschnitt 5.1.

4.2 Protokolle abrufen

Protokolle werden auch mit dem Befehlszeilentool cmd183.exe abgerufen. Erstellen Sie zunächst einen Ordner auf dem Host-Computer, in dem die Protokolle gespeichert werden sollen. Führen Sie dann „cmd183.exe getlogs“ aus, wobei der Speicherort des erstellten Ordners ersetzt wird. Sobald die Protokolle erfolgreich abgerufen wurden, werden sie von der/den ActiveSQX-Karte(n) gelöscht. Alle Protokolldateien haben ein an den Dateinamen angehängtes Datum und eine Uhrzeit sowie eine ID, sodass jedes Clientfenster über eine eigene, eindeutige Protokolldatei verfügt. Der Inhalt des Ordners kann dann gezippt und zurückgesendet werden Datapath zur weiteren Analyse. Abhängig vom Ergebnis Datapath kann eine weitere Protokollierung mit verschiedenen Optionen anfordern, um das Problem einzugrenzen.

4.3 Paketverlust und Jitter erkennen

Wenn das Netzwerk unter Paketverlust und/oder Jitter zu leiden scheint, weil das Video Dekodierungsartefakte aufweist, aktivieren Sie die folgende Protokollierung:

cmd183.exe Setlog-Datei –g rtpsource:5

Öffnen Sie den IP-Stream und lassen Sie ihn etwa eine Minute lang laufen. Rufen Sie dann die Protokolle mit dem Befehl getlogs ab. Suchen Sie in sqx-client-child_xxx.log nach Zeilen, die so aussehen:

rtp_source_get_new_rb: Bruchteil 0, verloren 1, extseq 120132, Jitter 98

Fraktion Gibt die Anzahl der verlorenen Pakete im Bereich von 0 bis 256 an, umzuwandeln in eine prozentuale Division durch 2.56. Lost gibt die Anzahl der seit dem letzten Bericht verlorenen Pakete an. Leider können bereits geringe Paketverluste zu großen Dekodierungsartefakten führen. Nehmen Sie zum Beispiel ein H264-codiertes Video, das mithilfe von RTP-Paketen mit einer Bitrate von 8 Mbit/s bei 30 Bildern pro Sekunde und einer GOP-Größe von 30 übertragen wird. Viele IP-Quellen codieren ganze Frames in eine einzige H264-NAL-Einheit, also jedes Frame beträgt also durchschnittlich etwa 34 KB. Die maximale Übertragungsgröße eines Pakets beträgt typischerweise etwa 1.5 KB, sodass ein Frame in etwa 23 RTP-Pakete aufgeteilt werden muss. Aufgrund der Funktionsweise des RTP-Protokolls müssen alle Pakete verworfen werden, wenn eines dieser 23 Pakete verloren geht. Ein einzelnes verlorenes Paket kann in diesem Beispiel also tatsächlich dazu führen, dass 23 Pakete verworfen werden. Sobald ein Frame verloren geht, treten bei allen nachfolgenden Frames Dekodierungsartefakte auf, bis der nächste I-Frame eintrifft, der in diesem Beispiel bis zu 29 Frames umfassen kann. Ein Paketverlust von nur 0.1 % könnte dazu führen, dass bis zu 66 % der Frames beschädigt sind (0.1 * 23 * 29). Um eine reibungslose und artefaktfreie Videowiedergabe zu erreichen, ist es daher wichtig, den Paketverlust so weit wie möglich zu minimieren, idealerweise ganz zu eliminieren.

Jitter ist die Variation der Verzögerung empfangener Pakete im Stream in Taktrateneinheiten. Sie wird gemessen, indem das Intervall, in dem RTP-Pakete gesendet wurden, mit dem Intervall, in dem sie empfangen wurden, verglichen wird. Wenn beispielsweise Paket Nr. 1 und Paket Nr. 2 50 Millisekunden voneinander entfernt sind und 60 Millisekunden voneinander entfernt ankommen, beträgt der Jitter 10 Millisekunden. Je niedriger der Jitter-Wert, desto besser. Hohe Jitter-Werte weisen darauf hin, dass Pakete nicht in regelmäßigen Abständen eintreffen und mehr Caching erforderlich ist, um eine reibungslose Wiedergabe zu erreichen. Jitter ist im Allgemeinen weniger problematisch als Paketverlust, da er von ActiveSQX durch eine Erhöhung des Cachings ausgeglichen werden kann.

4.4 IGMP-Multicast-Probleme

Wenn ein Multicast-IP-Stream nach einer bestimmten Zeit (einige Minuten, Stunden oder sogar Tage) unterbrochen wird, liegt möglicherweise ein Konfigurationsproblem bei den Switches vor, die zur Übertragung der Multicast-Pakete verwendet werden. Wenn dies der Fall ist, wird im Fenster die Fehlermeldung „Verbindung beendet“ angezeigt. Wir können überprüfen, ob die RTP-Pakete nicht mehr empfangen werden, indem wir die folgende Protokollierung aktivieren:

cmd183.exe Setlog-Datei –s 2 –g rtpsource:5 –n igmp

Öffnen Sie den IP-Stream und lassen Sie ihn laufen, bis der Stream abbricht. Rufen Sie dann die Protokolle mit dem Befehl getlogs ab. Suchen Sie in sqx-client-child_xxx.log nach den Zeilen „Keine Frames übertragen für mehr als 1 Sekunde“ und „Ende des Streams als Zeitüberschreitung behandeln“. Dazwischen ist die Anzahl der empfangenen RTP-Pakete zu sehen. Wenn sich diese Zahl zwischen der Dekodierung des letzten Frames und dem Timeout nicht erhöht hat, bedeutet dies, dass keine neuen RTP-Pakete eingehen, und könnte auf einen Switch hinweisen, der die Pakete herausfiltert.

Unter der Annahme, dass die Pakete gestoppt wurden, können wir uns die IGMP-Pakete ansehen, um zu sehen, ob sie sich wie erwartet verhalten. Öffnen Sie sqx-client_xxx.pcap mit Wireshark und suchen Sie nach „Membership Query, general“-Paketen, die vom Switch kommen. Stellen Sie sicher, dass jede Anfrage innerhalb der maximalen Antwortzeit, die im Abfragepaket für die verbundene Multicast-Adresse angegeben ist, mit einem „Mitgliedschaftsbericht“ beantwortet wird. Wenn ein anderes Gerät vor dem ActiveSQX mit einem Bericht antwortet, sendet der ActiveSQX ebenfalls keine Antwort (dies ist Teil des IGMP-Protokollstandards). In einigen Fällen erhält ActiveSQX möglicherweise einen Bericht von einem anderen Gerät, den es nicht erhalten sollte. Dies weist auf ein Problem mit der Netzwerkkonfiguration hin.

5 Anhänge

5.1 Protokollierungsarten

Protokolldateien können entweder auf dem ActiveSQX gespeichert oder live an den Host-Computer gesendet werden, während sie mit DebugView oder einem Kernel-Debugger generiert und angezeigt werden. Das Schreiben in Dateien auf dem ActiveSQX ist tendenziell schneller und beeinträchtigt den Dekodierungsprozess nicht so sehr, aber der ActiveSQX verfügt nur über begrenzten Speicherplatz für die Protokollierung (ca. 1.4 GB). Umgekehrt ist die Anzeige der Protokolle in DebugView nicht durch den Speicherplatz von ActiveSQX begrenzt, kann jedoch die Leistung erheblich beeinträchtigen, wenn eine sehr ausführliche Protokollierung aktiviert ist.

Es können verschiedene Arten der Protokollierung aktiviert werden:

• SQX: Protokollnachrichten, die von stammen Datapathist proprietärer Code.
• GStreamer: Protokollnachrichten, die aus Open-Source-GStreamer-Code stammen.
• GStreamer-Pipeline: grafische Darstellung der GStreamer-Pipeline.
• Erfassung von Netzwerkpaketen: Rohdaten von Netzwerkpaketen, die in Wireshark angezeigt werden können.

Abhängig von der Art des Problems können beliebig viele dieser Protokolle gleichzeitig aktiviert werden, wobei die Einschränkungen des Speicherplatzes und die Auswirkungen auf die Leistung zu berücksichtigen sind. Der beste Ansatz besteht darin, mit einer relativ geringen Protokollierung zu beginnen und darin nach Fehlern und Warnungen zu suchen. Wenn dann die Ursache des Problems offensichtlicher wird, können erhöhte Protokollierungsstufen aktiviert werden.

5.1.1 SQX-Protokollierung

Die SQX-Protokollierung erfolgt in 4 Stufen: 0 bis 3. 0 bedeutet keine Protokollierung, 1 nur Fehler, 2 Fehler und Warnungen und 3 vollständige Protokollierung. Protokollstufe 2 ist für den Anfang eine gute Stufe, da sie die Festplatte nicht zu schnell füllen sollte. Beispiel: cmd183.exe setlog file –s 2

5.1.2 GStreamer-Protokollierung

Die GStreamer-Protokollierung ist komplizierter und umfasst 10 Protokollebenen 0 bis 9. Zusätzlich zur Protokollebene verfügt GStreamer über eine Reihe unterschiedlicher Debug-Kategorien für verschiedene Komponenten innerhalb der GStreamer-Architektur. Es ist beispielsweise möglich, Debug-Level 9 speziell für die Kategorie „rtpsource“ zu aktivieren, während alle anderen Kategorien deaktiviert bleiben. Weitere Informationen finden Sie in der Variablen GST_DEBUG weiter unten http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gst-running.html. Level 4 in allen Kategorien ist im Allgemeinen ein guter Ausgangspunkt, da es ein Gleichgewicht zwischen der Bereitstellung ausreichender Informationen und dem Vermeiden einer zu schnellen Belegung des Speicherplatzes schafft. Beispiel: cmd183.exe setlog file –g 4 oder cmd183.exe setlog file –g rtpsource:5

5.1.3 Pipeline-Protokollierung

GStreamer hat auch die Möglichkeit, die Pipeline in eine .dot-Datei auszugeben, die nach der Verarbeitung durch graphviz eine grafische Darstellung der Pipeline liefert, die einen guten Hinweis darauf gibt, welche Codierungsformate und Transportprotokolle von einer bestimmten IP-Quelle verwendet werden. Beispiel: cmd183.exe setlog file -p

5.1.4 Paketprotokollierung

Wenn das Problem nicht allein anhand der Protokolldateien diagnostiziert werden kann, ist es möglicherweise erforderlich, rohe Netzwerkpakete zu erfassen und in Wireshark zu analysieren. Bei intermittierenden Problemen kann es auch eine bequeme Möglichkeit sein, selten auftretende Probleme zu reproduzieren. Es ist jedoch zu beachten, dass der Festplattenspeicher sehr schnell voll werden kann, wenn alle Pakete erfasst werden. Um dieses Problem zu lindern und den Kunden ein gewisses Maß an Privatsphäre zu bieten, ist es möglich, erfasste Pakete anhand bestimmter Kriterien zu filtern. Tcpdump wird für die Paketerfassung verwendet und die Filtersyntax wird hier ausführlich beschrieben http://www.tcpdump.org/manpages/pcap-filter.7.html. Beispiel: cmd183.exe setlog file –n „src 10.20.0.1“ oder cmd183.exe setlog file –n „ “ für keine Filterung.

Der Promiscuous-Modus ist deaktiviert, um zu vermeiden, dass allgemeiner Netzwerkverkehr erfasst wird, der nicht für ActiveSQX bestimmt ist. Da die Paketerfassung jedoch auf einer niedrigen Ebene erfolgt, kann sie potenziell vertrauliche Informationen erfassen, je nachdem, welche Informationen über das Netzwerk gesendet werden, wenn sie nicht explizit herausgefiltert werden. Es ist auch möglich, Videos von den Paketerfassungen wiederzugeben. Kunden sollten darüber informiert werden, bevor sie darum gebeten werden, Paketerfassungen an zurückzusenden Datapath. Aus diesen Gründen sollte die Paketerfassung im Allgemeinen als letztes Mittel zur Fehlerbehebung verwendet werden.