Jak czytać SIP trace i znaleźć przyczynę błędu połączenia

Zacznij od pytania, na które trace ma odpowiedzieć#

Najczęstszy błąd w analizie SIP nie polega na przeoczeniu pojedynczego nagłówka. Problem zaczyna się wcześniej: ktoś otwiera PCAP albo sngrep, przewija setki komunikatów i próbuje znaleźć „coś dziwnego”, nie definiując objawu. Tymczasem inny zestaw danych jest potrzebny dla braku zestawienia, inny dla rozłączenia po 30 sekundach, a jeszcze inny dla jednokierunkowego audio.

Przed analizą zapisz cztery informacje:

• kto inicjuje połączenie i jaki numer wybiera,
• o której godzinie wystąpił problem oraz w jakiej strefie czasowej,
• jaki był obserwowany efekt: brak dzwonienia, błąd, cisza, rozłączenie, niewłaściwy numer prezentowany,
• jaki rezultat był oczekiwany.

Ta krótka definicja ogranicza zakres i pozwala odróżnić sygnalizację od mediów. Przykład: „A dzwoni do B, B odbiera, A nie słyszy B” prowadzi do analizy SDP i RTP. „A dzwoni do B, ale operator zwraca 403” wymaga przede wszystkim oceny routingu, tożsamości i polityki operatora.

Ustal granice dialogu: Call-ID, tagi i transakcje#

Pierwszym punktem odniesienia jest zwykle Call-ID. Pozwala zebrać komunikaty należące do jednego dialogu, ale nie należy traktować go jak uniwersalnego identyfikatora całej rozmowy biznesowej. Transfer, B2BUA, kolejny mostek albo wyjście do operatora mogą utworzyć nowy dialog i nowe Call-ID.

W Wiresharku przydatny jest filtr:

sip.Call-ID == "przykladowe-call-id@pbx.example"

Następnie sprawdź:

1. pierwszy INVITE,
2. odpowiedzi tymczasowe 100, 180 lub 183,
3. odpowiedź końcową,
4. ACK,
5. ewentualne re-INVITE lub UPDATE,
6. sposób zakończenia: BYE, CANCEL albo odpowiedź błędna.

Tagi w From i To pomagają rozpoznać dialog. Parametr branch w Via identyfikuje transakcję. Numer CSeq wskazuje kolejność metod w dialogu. Dzięki temu można odróżnić ponowienie tego samego żądania od nowej negocjacji.

Czytaj przepływ od lewej do prawej, ale porównuj oba legi#

W systemie z PBX, SBC albo B2BUA jedna rozmowa składa się co najmniej z dwóch legów. Komunikat otrzymany od telefonu nie musi zostać wysłany do operatora w identycznej postaci. System może zmienić Request-URI, domenę, identyfikację, SDP, kolejność kodeków, nagłówki prywatności lub informacje o przekierowaniu.

Dlatego dla każdego istotnego etapu porównaj wejście i wyjście:

Jeżeli błąd pojawia się dopiero na legu wychodzącym, przyczyny należy szukać w dialplanie, profilu SIP, translacji nagłówków albo konfiguracji gatewaya. Jeżeli nieprawidłowa wartość przychodzi już od urządzenia, trzeba ocenić provisioning lub logikę klienta.

Interpretuj odpowiedzi w kontekście transakcji#

Kod odpowiedzi jest początkiem analizy, nie jej końcem. 404 Not Found może oznaczać brak numeru w systemie docelowym, niepasujący format numeracji albo zły tenant. 403 Forbidden może wynikać z polityki tożsamości, autoryzacji, klasy usług, limitu lub blokady antyfraudowej. 488 Not Acceptable Here często kieruje uwagę na SDP i kodeki, ale może dotyczyć również innych parametrów sesji.

Praktyczna kolejność:

• ustal, które urządzenie wygenerowało odpowiedź,
• odczytaj Reason, tekst statusu i ewentualne nagłówki operatorskie,
• sprawdź, czy PBX przepisał kod przed przekazaniem go do inicjatora,
• porównaj z działającym połączeniem do tego samego celu,
• zweryfikuj, czy problem jest stały, zależny od numeru, użytkownika, gatewaya lub pory dnia.

Odpowiedź 200 OK nie kończy diagnostyki. Potwierdza zakończenie transakcji INVITE sukcesem, ale połączenie może nadal mieć błędne media, niezgodny kierunek RTP albo zostać rozłączone przez timeout sesji.

Sprawdź routing i tożsamość#

W pierwszym INVITE przeanalizuj co najmniej:

• Request-URI,
• To i From,
• P-Asserted-Identity lub P-Preferred-Identity,
• Diversion oraz History-Info, jeśli połączenie było przekierowane,
• Route i Record-Route,
• Max-Forwards,
• nagłówki specyficzne dla operatora lub tenanta.

Nie zakładaj, że From jest jedyną tożsamością używaną przez operatora. W wielu integracjach operator autoryzuje numer na podstawie PAI, a From pozostaje wartością prezentowaną użytkownikowi. Przy połączeniach przekierowanych często istotny jest również Diversion.

Zwróć uwagę na format numerów. Ten sam numer może pojawić się jako 0048..., +48..., format krajowy albo lokalny. Jeżeli dialplan normalizuje numer na jednym legu, a reguła operatora oczekuje innego formatu, odpowiedź błędna będzie wyglądała jak problem po stronie operatora, choć źródłem jest lokalna translacja.

Przejdź do SDP dopiero po potwierdzeniu sygnalizacji#

SDP opisuje plan mediów. Najważniejsze pola to:

c=IN IP4 203.0.113.20
m=audio 24578 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

Sprawdź adres w c=, port w m=audio, profil transportowy, listę payload types, mapowania rtpmap, kierunek sendrecv/sendonly/recvonly/inactive oraz parametry DTMF. W WebRTC dochodzą ICE, fingerprint DTLS i kandydaci.

Porównaj offer i answer. Odpowiedź powinna zawierać wspólny kodek i realnie osiągalny adres mediów. Jeżeli PBX kotwiczy media, oba urządzenia powinny wysyłać RTP do PBX, a nie bezpośrednio do prywatnego adresu drugiej strony.

Połącz SIP z RTP i czasem zdarzeń#

Gdy sygnalizacja wygląda poprawnie, sprawdź RTP. W Wiresharku użyj Telephony → RTP → RTP Streams albo filtrów dla wybranych adresów i portów. Odpowiedz na pytania:

• czy pakiety płyną w obu kierunkach,
• czy źródło i cel odpowiadają SDP,
• czy strumień zaczyna się po odebraniu,
• czy sekwencja i timestampy są ciągłe,
• czy występuje utrata, jitter albo zmiana SSRC,
• czy firewall lub NAT nie zmienia kierunku po kilku sekundach.

Ważna jest korelacja czasu. Rozłączenie dokładnie po 30–32 sekundach często wskazuje brak ACK albo problem z dotarciem kolejnego żądania w dialogu. Rozłączenie po określonym Session-Expires prowadzi do analizy refreshera i re-INVITE/UPDATE. Brak audio od pierwszej chwili częściej wynika z SDP, routingu RTP lub ACL.

Porównanie good call i bad call#

Najskuteczniejsza metoda przy problemach sporadycznych to porównanie działającego i niedziałającego przykładu o możliwie podobnych parametrach. Nie porównuj wyłącznie kolejności komunikatów. Zbuduj listę różnic:

• węzły i adresy IP,
• wybrany gateway,
• format numeru,
• nagłówki tożsamości,
• kolejność i zawartość SDP,
• kodek końcowy,
• czasy między komunikatami,
• powód zakończenia,
• kierunek i statystyki RTP.

Różnica nie musi być przyczyną. Jeżeli good call używa innego gatewaya, to jest trop, ale nadal trzeba ustalić, jaka cecha gatewaya wpływa na wynik: routing, ACL, kodek, nagłówki czy dostępność.

Zakończ analizę weryfikowalnym RCA#

Dobre RCA powinno rozdzielać fakty, wniosek i działanie. Przykład:

• Fakt: operator zwrócił 403 po otrzymaniu PAI z numerem wewnętrznym.
• Fakt: w działającym połączeniu PAI zawiera przypisany DID.
• Wniosek: transformacja tożsamości nie została wykonana dla ścieżki przekierowanej.
• Poprawka: ujednolicić regułę PAI dla połączeń bezpośrednich i przekierowanych.
• Weryfikacja: powtórzyć test dla obu scenariuszy i potwierdzić PAI oraz odpowiedź operatora.
• Prewencja: dodać test regresyjny lub kontrolę konfiguracji dla nowych tenantów.

Taka forma jest bardziej użyteczna niż stwierdzenie „problem z nagłówkiem”. Pozwala wdrożyć zmianę, sprawdzić ją i zapobiec powrotowi błędu.

Checklista analizy SIP trace#

1. Zdefiniuj objaw i oczekiwany rezultat.
2. Zbierz Call-ID oraz powiązane dialogi.
3. Ustal, kto wygenerował każdą odpowiedź.
4. Porównaj leg przychodzący i wychodzący.
5. Zweryfikuj routing, numerację i tożsamość.
6. Przeanalizuj offer/answer SDP.
7. Sprawdź RTP i korelację czasową.
8. Porównaj good call z bad call.
9. Sformułuj RCA jako fakty, przyczynę, poprawkę i test.
10. Zapisz dowód po wdrożeniu zmiany.