Jeżeli w naszej sieci występują problemy z komunikacją telefonii IP, to Wireshark będzie bardzo przydatnym narzędziem pozwalającym je zidentyfikować lub zawęzić ich obszar poszukiwania. Wireshark wyposażony jest w szereg narzędzi pozwalających na dekodowanie i analizowanie zarówno wiadomości kontrolnych (na przykład protokołu sygnalizacyjnego SIP), jak i strumienia danych z głosem.

Analiza sygnalizacji

W zależności od zdiagnozowanego problemu powinniśmy zebrać pakiety w czasie pojedynczego, problematycznego połączenia lub zbierać je przez określony czas, aby przeanalizować wiele połączeń jednocześnie. Analizę zawsze rozpoczynamy od protokołu sygnalizacyjnego, takiego jak SIP. Bez poprawnego ustanowienia połączenia przez centralę telefonii IP, nie byłoby możliwe zestawienie kanału głosowego pomiędzy urządzeniami końcowymi. Analizując wiadomości protokołu SIP, prześledzimy proces logowania czy wylogowania się klienta. Jeżeli problem występuje jedynie dla pojedynczego klienta, powinniśmy zbierać logi na urządzeniu, na którym jest połączenie wykonywane lub z urządzenia sieciowego znajdującego się najbliżej klienta. Jeżeli zaś problem dotyczy wielu klientów, to pakiety raczej będziemy rejestrować na serwerze, na którym zainstalowana jest centrala telefonii IP.

Na początek z zebranych danychwarto odfiltrowywać jedynie komunikację SIP i RTP. SIP to protokół sygnalizacyjny, RTP to protokół przenoszący strumień audio. Wystarczy do tego prosty filtr.

Następnie z menu Telephony, wybieramy SIP Flows, aby wyświetlić wykrytą w zebranych pakietach komunikację kontrolną.

Znajdziemy tu także informacje o wszelkich komunikatach, które zostały przechwycone przez Wiresharka. Program automatycznie dekoduje informacje zapisane w komunikatach SIP, dlatego od razu widzimy kto nawiązywał połączenie, z jakiego numeru i do jakiego numeru docelowego, a także, jaki był status tego połączenia. Z powyższego zrzutu widać, że tylko ostatnie połączenie zostało nawiązane poprawnie. Wszystkie poprzednie były z różnych względów odrzucane. Jeżeli chcemy odczytać szczegóły komunikatu wystarczy, że klikniemy dwukrotnie w wybraną pozycję i w głównym oknie programu. Automatycznie zostaniemy przeniesieni do pakietu rozpoczynającego dane połączenie. W komunikacie, będącym próbą nawiązania połączenia z innym numerem (INVITE), znajdziemy dokładne informacje o numerze docelowym (102), serwerze telefonii IP, do którego żądanie zostało skierowane (172.16.1.34) czy informacje o używanym telefonie IP (MYVOIPAPP SIP Phone (Apr 23 2022)). W sekcji Session Description Protocol  znajdują się znowu informacje, które mają pozwolić nawiązać strumień audio pomiędzy urządzeniami końcowymi. To tutaj znajdują się, między innymi, propozycje, jaki kodek może zostać zastosowany do transmisji głosu oraz, jaki port będzie do tego celu wykorzystywany.

Wszystkie te informacje są zgodne ze standardem SIP. Znaczenie poszczególnych pól możemy znaleźć w dokumentacji technicznej protokołu.

Problemy ze strumieniem audio

Jeżeli połączenie się zestawia, a nadawca czy odbiorca nie słyszy drugiego rozmówcy lub,  w jakikolwiek sposób, strumień audio nie jest wyraźny bądź jest zakłócony –  to musimy przeanalizować wiadomości protokołu RTP. Rozpoczynamy od prześledzenia czy strumień audio zestawia się dwukierunkowo. W tym celu z menu Statistics wybieramy Graph Flow, aby wyświetlić graf komunikacji połączenia. Bardzo szybko z niego odczytamy, analizując wektory strzałek wskazujące na kierunek przesyłania poszczególnych pakietów, czy komunikacja jest dwukierunkowa.

Także na tym etapie możemy odczytać podstawowe informacje na temat utworzonego strumienia audio, w tym, między innymi, jaki kodek został wykorzystany oraz porty, na których połączenie jest nawiązane. Również z tego grafu dowiemy się czy przypadkiem nie następuje duża utrata komunikatów RTP.

Dla każdego z identyfikowanych strumieni audio możemy wyświetlić jego szczegółowe informacje, wybierając z menu Telephony opcję RTP->RTP Streams. Da ono nam dostęp do dodatkowych parametrów, między innymi współczynnika utraty pakietów czy Jitter.

Bardzo szczegółowe informacje o każdym strumieniu znajdziemy w Telephony->RTP->RTP Stream Analysis. Tam odszukamy, między innymi, graf przedstawiający obrazowo zebrane dane – czasem łatwiej problem wyłapać, kiedy jest on zwizualizowany.

Zebrane w ten sposób strumienie audio możemy także odtworzyć. Dzięki temu, skorelujemy potencjalne problemy z dźwiękiem z konkretnymi zdarzeniami w sieci lub wartościami zapisanymi w komunikatach RTP.