Najpierw nazwij brakujący kierunek#

„One-way audio” jest zbyt ogólnym opisem. Trzeba ustalić, kto kogo nie słyszy i z której perspektywy opisujemy kierunek. Jeżeli użytkownik A nie słyszy B, brakuje ścieżki B → A, nawet jeśli zgłoszenie mówi „brak audio po stronie A”. Ta różnica zapobiega analizowaniu niewłaściwego strumienia.

Zapisz cztery punkty końcowe:

  • urządzenie A,
  • serwer lub media proxy po stronie A,
  • serwer lub operator po stronie B,
  • urządzenie B.

Następnie narysuj oczekiwane strumienie RTP. W systemie z kotwiczeniem mediów zwykle wyglądają tak:

text
A  <---- RTP ---->  PBX / SBC  <---- RTP ---->  B

Jeśli PBX nie kotwiczy mediów, urządzenia mogą próbować komunikować się bezpośrednio. Wtedy prywatny adres w SDP, asymetryczny routing albo restrykcyjny NAT stają się szczególnie istotne.

SDP mówi, gdzie media powinny płynąć#

SIP zestawia sesję, a SDP opisuje jej parametry. Dla każdego legu sprawdź c= i m=audio:

sdp
c=IN IP4 198.51.100.40
m=audio 18462 RTP/AVP 0 8 101
a=sendrecv

Adres 198.51.100.40 i port 18462 są deklarowanym celem RTP dla drugiej strony. W systemie za NAT aplikacja może widzieć adres prywatny interfejsu, podczas gdy zewnętrzny peer potrzebuje adresu publicznego. Profil SIP lub SBC powinien wtedy wystawić właściwy adres zewnętrzny.

Nie zakładaj jednak, że każdy adres RFC1918 jest błędny. W prywatnym MPLS, VPN albo wydzielonym interconnect taki adres może być prawidłowy. Liczy się osiągalność z perspektywy peerów na danym legu.

Porównaj offer i answer:

  • czy oba kierunki uzgodniły kodek,
  • czy port nie jest równy 0, co oznacza odrzucenie strumienia,
  • czy kierunek nie został ustawiony na sendonly, recvonly albo inactive,
  • czy po re-INVITE adres lub port nie zmienił się na nieosiągalny,
  • czy profil RTP (RTP/AVP, RTP/SAVP, UDP/TLS/RTP/SAVPF) jest zgodny z możliwościami stron.

RTP pokazuje, co dzieje się naprawdę#

Po ustaleniu deklarowanych celów przejdź do pakietów. Dla każdego segmentu zapisz:

SegmentŹródłoCel z SDPPakiety widoczne?Wniosek
A → PBXtelefon Aport PBXtak / nieczy A wysyła i czy sieć dostarcza
PBX → BPBXport operatora/Btak / nieczy serwer przekazuje media
B → PBXoperator/Bport PBXtak / nieczy powrót dociera do serwera
PBX → APBXport telefonu/NATtak / nieczy PBX ma poprawny cel dla A

Jeżeli RTP dochodzi do PBX od B, ale PBX nie wysyła go do A, problem może dotyczyć mostka, kodeka, błędnego stanu kanału lub konfiguracji media bypass. Jeżeli PBX wysyła do A, ale pakietów nie widać po stronie klienta, należy sprawdzić firewall, NAT i trasę.

W Wiresharku pomocne są statystyki RTP: SSRC, sequence number, timestamp, jitter i utrata. Sam fakt obecności UDP nie wystarczy. Pakiety mogą trafiać na zły port, mieć inny payload type albo należeć do starego strumienia po renegocjacji.

NAT zmienia więcej niż adres#

NAT tworzy mapowanie pomiędzy adresem prywatnym i publicznym. Dla UDP mapowanie może zależeć od adresu docelowego, czasu bezczynności i implementacji urządzenia. Typowy scenariusz:

  1. telefon deklaruje w SDP prywatny adres,
  2. wysyła RTP z publicznego mapowania utworzonego przez NAT,
  3. serwer otrzymuje pakiety z innego adresu lub portu niż w SDP,
  4. serwer musi zdecydować, czy odpowiadać na adres z SDP, czy na rzeczywiste źródło.

Mechanizm symmetric RTP polega na wysyłaniu odpowiedzi do adresu i portu, z których faktycznie nadeszły media. Pomaga w wielu sieciach NAT, ale nie naprawi sytuacji, w której telefon w ogóle nie wysyła RTP albo firewall blokuje pakiety wychodzące.

Firewall: port otwarty nie oznacza poprawnej ścieżki#

Sprawdzenie reguły typu „UDP 10000–40000 ACCEPT” jest dopiero początkiem. Należy potwierdzić:

  • na którym interfejsie ruch wchodzi i wychodzi,
  • czy reguła dotyczy właściwego adresu źródłowego,
  • czy host ma poprawną trasę zwrotną,
  • czy conntrack nie wiąże strumienia z innym tuplem,
  • czy Docker lub inne reguły NAT nie zmieniają kolejności przetwarzania,
  • czy chmura ma dodatkowy security group lub ACL,
  • czy operator wysyła z adresów zgodnych z allowlistą.

Do obserwacji użyj jednocześnie tcpdump na interfejsie zewnętrznym i wewnętrznym. Przykładowo:

bash
tcpdump -ni any udp portrange 10000-40000 -w /tmp/rtp-check.pcap

Filtr any ułatwia szybkie potwierdzenie obecności ruchu, ale przy analizie kierunku warto wykonać osobne capture na konkretnych interfejsach. W przeciwnym razie ten sam pakiet może pojawić się więcej niż raz.

Media proxy, bypass i nieoczekiwane skróty#

PBX może kotwiczyć media albo zezwalać na bezpośredni przepływ. Media bypass zmniejsza obciążenie serwera, lecz zwiększa wymagania wobec sieci między endpointami. Jeżeli jeden klient jest w LAN, drugi za CGNAT, a operator oczekuje publicznego adresu SBC, bezpośrednie media będą nieprzewidywalne.

Sprawdź, czy:

  • bypass_media lub odpowiednik jest włączony,
  • re-INVITE próbuje połączyć endpointy bezpośrednio,
  • SBC przepisuje SDP na obu legach,
  • transcoding wymusza kotwiczenie mediów,
  • nagrywanie, IVR lub kolejka zmienia ścieżkę RTP,
  • po transferze powstaje nowy mostek z innymi portami.

Jednokierunkowe audio po transferze często nie ma tej samej przyczyny co problem w pierwotnym połączeniu. Nowy dialog może używać innego profilu, gatewaya lub polityki NAT.

Kodek może wyglądać jak problem sieciowy#

Jeżeli pakiety są widoczne w obu kierunkach, sprawdź payload type i negocjację. Dynamiczny payload type ma znaczenie tylko w kontekście konkretnego SDP. Payload 101 zwykle oznacza telephone-event, ale nie jest to wartość gwarantowana bez a=rtpmap.

Typowe problemy:

  • offer zawiera G.729, answer wybiera G.729, ale moduł kodeka nie jest dostępny,
  • endpoint wysyła payload type inny niż uzgodniony,
  • jeden leg używa SRTP, drugi oczekuje RTP bez poprawnej terminacji,
  • ptime lub packetization nie jest obsługiwane przez jedno urządzenie,
  • transcoder działa tylko w jednym kierunku albo kanał ma błędny read/write codec.

W FreeSWITCH lub innym B2BUA sprawdź osobno kodek odczytu i zapisu dla obu kanałów. To, że CDR pokazuje jeden kodek, nie musi opisywać całego mostka.

WebRTC dodaje ICE, DTLS i TURN#

W WebRTC adres z pojedynczej linii c= nie wystarcza. Kandydaci ICE opisują możliwe ścieżki: host, server reflexive i relay. Wybrana para kandydatów decyduje, gdzie faktycznie płyną media. Jeżeli połączenie działa w jednej sieci, a nie działa za restrykcyjnym NAT, sprawdź TURN oraz zakres portów relay.

Analizuj:

  • stan ICE i wybraną candidate pair,
  • czy kandydat relay jest osiągalny,
  • DTLS handshake i fingerprint,
  • SRTP po zakończeniu DTLS,
  • zgodność portów TURN z firewallem,
  • różnicę pomiędzy UDP, TCP i TLS relay.

Szczegółowy model znajduje się w artykule WebRTC, ICE, STUN i TURN bez skrótów.

Metodyka, która skraca diagnozę#

  1. Nazwij brakujący kierunek: A nie słyszy B oznacza problem B → A.
  2. Zbierz SIP i RTP z możliwie wielu punktów ścieżki.
  3. Rozpisz cele mediów z SDP dla każdego legu.
  4. Potwierdź rzeczywiste źródła i cele pakietów.
  5. Sprawdź NAT, trasę zwrotną i reguły na wszystkich warstwach.
  6. Zweryfikuj kotwiczenie mediów, bypass i renegocjacje.
  7. Potwierdź payload types, kodeki i profil bezpieczeństwa.
  8. Porównaj działający i niedziałający przypadek.
  9. Wprowadź jedną zmianę i powtórz capture.

Najważniejszy jest dowód na każdym odcinku. „RTP wychodzi z PBX” nie oznacza, że dociera do telefonu. „Firewall jest otwarty” nie oznacza, że SDP wskazuje osiągalny adres. Dopiero połączenie sygnalizacji, pakietów i topologii daje wiarygodne RCA.