Skype-Debugging
Herausforderungen der Skype-Analyse
Für die Skype-Konferenz ist alles vorbereitet. Doch dann streikt die Technik. Während Nutzer Defekte an Kamera, Kabel und Mikrofonen meist zügig beheben können, bedarf es bei schlechter Skype-Verbindung einer tiefergehenden Protokollanalyse.
Die Entwicklung von Skype begann 2003 und im Jahr 2011 erfolgte die Übernahme von Microsoft. Anfänglich als Peer-to-Peer-System gestartet, sind nun dedizierte Microsoft-Server in Gebrauch. Der Global Player integrierte den Dienst als wichtigen Baustein in seine Angebotspalette, die sich vor allem auch an Unternehmen richtet. Alle Office-365-User haben automatisch Skype integriert, alle neuen Unternehmensabos enthalten Teams (ehemals Skype for Business). Die Anwendung ermöglicht Einzel- und Gruppengespräche, Videotelefonie und -konferenzen. Viele Unternehmen setzen sie zunehmend als VoIP-Alternative ein, und der Funktionszuwachs macht sie mehr und mehr zur multimedialen Business-Lösung.
Das zweite Quartal 2020 war für viele Firmen von gesellschaftlichen Einschränkungen geprägt. Die Unternehmen mussten ihre Kommunikation partiell in den digitalen Raum verlagern. Viele Unternehmen setzen deshalb vermehrt auf Telefonkonferenzen und virtuelle Meetings.
Protokollanalyse für den Skype-Verkehr
Fragen bezüglich der Client-Anbindung, des Skype-Servers und der Server- oder Netzüberlastung betreffen vor allem die Qualität von Verbindung, Service und Konfiguration. Bei den Servern von Microsoft vermutet man ständige Verfügbarkeit bei gleichzeitig hohen Geschwindigkeitsraten. Dennoch können Nutzer sich die Fragen stellen, wie der Datendurchsatz im eigenen Netz aussieht und ob alle Pakete an- und durch die Firewall kommen. Die Wege eines Skype-Pakets können von Hindernissen beeinträchtigt sein.
Klagt also ein Mitarbeiter über eine schlechte Verbindung, benötigt man detaillierte Netzwerkanalyse-Tools, um die Skype-Verbindungsdaten zu untersuchen und dem Fehler auf die Spur zu kommen. Der Umstand, dass der Content SSL- und RTP-verschlüsselt ist, erschwert die Analyse. Zudem verwendet Skype zum Verbindungsaufbau innerhalb von SSL kein Standardprotokoll wie zum Beispiel SIP, sondern ein proprietäres Protokoll, das sich damit auch jederzeit ändern könnte.
Zu Untersuchungszwecken soll nun eine Betrachtung der genutzten Protokolle und deren Parameter erfolgen. Da SSL TCP als Layer-4-Protokoll nutzt, können alle Statistiken zur TCP-Verbindungsqualität zum Debugging dienen. Darüber hinaus können einige SSL- und RTP-Verbindungsdaten in die Betrachtung miteinfließen.
Skype-Debugging in Echtzeit oder per Pcaps
Debugging ist das strukturierte Auffinden von Fehlern mit professionellen Mitteln. Ohne die Fehlersuche ist kein Beheben von Fehlern möglich. Um an die entsprechenden Daten zu gelangen, hilft ein Netzwerk-Debugger, der die Sichtbarkeit des Traffics ermöglicht, also alle relevanten Informationen der Verbindungen und Protokolle zur Verfügung stellt. Natürlich wäre es denkbar, damit bei einer Live-Verbindung zu messen und zu analysieren. Sinnvoller ist es sicher, sich ein Pcap einer entsprechenden Skype-Session zu erstellen und es dann nachträglich in Ruhe zu untersuchen. Sollte trotz Pcap nicht bekannt sein, wann und ob bei weiteren Usern die fehlerhafte Skype-Qualität auftrat, dann kann die Suchfunktion des Analyzers Abhilfe schaffe. Einige Debugger stellen eine Freitextsuche zur Verfügung, sodass eine Identifikation aller Skype-Benutzer möglich ist. Hat man Zugriff auf die Protokollstatistiken sowie die Skype-Verbindungen eingegrenzt, dann weiß der Administrator, wo er im Stack ansetzten möchte. Umfassend kann sich der Prüfer auch Stück für Stück anhand der Layer vorarbeiten und sich einen Gesamteindruck verschaffen.
IP und TCP geben Aufschluss
Sind die Skype-Nutzer und ihre IP-Adressen identifiziert, folgt die Betrachtung, mit welchen Skype-Servern sie verbunden waren. Auf Layer 4 ist der TCP-Traffic sichtbar. Dieser bemisst einen kleinen Anteil des gesamten Skype-Datenstroms. Diese Verbindungen sind für die Steuerungsinfos, den Kontrollverkehr und für den Aufbau und die Beendigung zuständig.
Verwendete DNS-Namen und IP-Adressbereiche können für Skype unterschiedlich sein, da die Steuerungs-Server in der Microsoft-Cloud einen Lastausgleich verwenden, der Daten auf verschiedene Server verweisen kann. Wie die Verbindung zustande gekommen ist, kann man sich in einer entsprechenden Lösung zur Netzwerkanalyse genau anzeigen lassen. Ein TCP-Modul misst dann die Zeit, die nötig ist, um die erste Antwort auf ein TCP-Verbindungsaufbaupaket zu erhalten. Die Paketumlaufzeit und die Auslastung des Servers beeinflusst diesen Wert. Es erfolgen die Berechnung und Anzeige eines Bewertungswerts basierend auf einem Bewertungsalgorithmus.
Bei einem erfolgreichen TCP-Handshake folgt danach der Versand relativ weniger Kontrolldaten über die Leitung. Wichtig sind dennoch die Zeiten, die für diese Kontrollverbindungen nötig sind. Sind die Antwortzeiten nicht konstant, deutet das auf eine schwankende Netzlast hin. Existieren zwischen dem Testgerät, dem Server oder dem Client Bursts im Netzwerk, können diese die Ursache für die schlechte Verbindung sein. Sind die TCP-Antwortzeiten sehr hoch, kann es daran liegen, dass der Microsoft-Server sich sehr weit entfernt befindet und die Laufzeit für Latenzen sorgt. TCP-Retransmissions können weitere spürbare Auswirkungen auslösen. Wenn der Skype-Client beim Einloggen immer lange braucht oder die Verbindung abreißt, kann das an der ausbleibenden Annahme der Datenpakete durch den Server liegen. Auch hier zeigt der Debugger, wie gut der Kontrollverkehr ist. Ist keinen Datendurchsatz vorhanden, kann dies am TCP-Zero-Window liegen. Dies bedeutet normalerweise, dass der TCP-Empfangspuffer des Systems, das das Zero-Window-Paket sendet, gefüllt ist und das System keine weiteren Daten für diese Verbindung empfangen kann. Eine Diagrammansicht hilft bei der Betrachtung der TCP-Zero-Window-Pakete über die gemessene Zeit.
Auf Layer 7 findet die Verwendung von SSL zur Verschlüsselung des Skype-Steuerungsverkehrs statt, zum Beispiel der Kontrollverkehr, die Login-Meta-Informationen und alle Nachrichten über die Microsoft-Server. Dagegen ist die Antwortzeit für den SSL-Handshake und die erste Antwortzeit für verschlüsselte SSL-Daten sichtbar.
So sind Handshake-Zeiten im zweistelligen Millisekundenbereich normal, ab dem dreistelligen Bereich können sie dagegen problematisch werden. Ein guter Netzwerk-Analyzer stellt mindestens die SSL-Handshake-Zeit, die SSL-Datenantwortzeit, die Anzahl der SSL-Anforderungen und Antworten, die minimale und maximale Antwortzeit in Millisekunden sowie die Qualität des SSL-Servers als Informationen zur Verfügung.
SSL und RTP
Das Versenden des Audio- und Videoverkehrs erfolgt über verschlüsselte RTP-Frames, wobei der Header nicht verschlüsselt ist. Skype nutzt eigene Sprach- beziehungsweise Medien-Codecs und überträgt den Content vollverschlüsselt. Da die RTP-Verschlüsselung also nur auf den Inhalt und nicht auf den RTP-Header angewandt ist, ist eine Untersuchung des RTP-Verkehrs möglich. Der Transport des RTP erfolgt mittels UDP und umfasst keine Transportsicherung. Die Kommunikation der Daten verläuft einseitig. Die verlorenen Daten nehmen Nutzer jedoch als abgehakte Sprachfetzen und ruckelnde Bilder wahr. Im Debugger kommt demnach Packet Loss als Fehlerquelle zur Untersuchung hinzu.
RTP-Pakete kommen im Idealfall gleichbleibend an. Eine Ungleichmäßigkeit führt zu schwankender Qualität. Gewünscht ist ein Datenstrom mit gleichbleibender, vorzugsweise niedriger Latenz. Die zeitkritische Anwendung wie Skype bedarf einer geringen Laufzeitschwankung. Ein typischer Jitter-Wert von zwei bis drei Millisekunden ist als unproblematisch einzustufen. Wenn der Jitter auf beispielsweise 50 Millisekunden steigt und verlorene Pakete erkennbar sind, gibt es wahrscheinlich ein Leitungsproblem. Das Netzwerkanalyse-Tool zeigt auf, welche IP-Adresse das Protokoll RTP verwendet hat. Es liefert eine Übersicht über die empfangenen und gesendeten Bits, den RTP-Paketverlust und den Jitter basierend auf den RTP-Sequenznummern.
- Herausforderungen der Skype-Analyse
- Falsche Route beeinflusst Skype-Qualität
Lesen Sie mehr zum Thema
