De ce un apel SIP se înregistrează prin VPN dar nu trimite audio
Înregistrarea și audio-ul urmează căi diferite. Urmăriți un apel prin tunel pentru a vedea ce adrese poate folosi PBX-ul și unde se oprește de fapt RTP.
O înregistrare reușită nu spune aproape nimic despre audio. Un softphone poate menține ore întregi o legătură validă cu PBX-ul biroului și totuși să livreze tăcere. Tunelul transportă doar pachetele pe care cineva le trimite deliberat în el, iar un apel folosește trei căi separate: legătura, stabilirea dialogului și fluxul RTP. Când le separați, defecțiunea cade pe o singură cale în loc de cuvântul VPN.
Imaginați-vă un laptop în Wi-Fi-ul de acasă care formează un post intern al biroului printr-un tunel aprobat. PBX-ul autentifică utilizatorul, acceptă REGISTER, iar postul apare ca disponibil, însă apelul se conectează cu tăcere totală într-o direcție.
Înregistrarea leagă un contact, nu o cale media
O cerere REGISTER îi cere înregistratorului să stocheze o corespondență între o adresă de înregistrare și unul sau mai multe URI de contact. Acea corespondență răspunde la o întrebare îngustă: unde trebuie trimis acum un dialog nou. Nu spune nimic despre unde aparțin mediile, iar o înregistrare acceptată nu dovedește că un INVITE ulterior poartă o adresă media accesibilă. Înregistrările expiră și după un temporizator, așa că un telefon care nu se mai reînnoiește pierde apelurile primite în timp ce tunelul său încă pare sănătos. Urmăriți expirarea contactului, nu starea tunelului.
Când softphone-ul stă în spatele tunelului, antetul de contact poate purta o adresă privată. Un PBX care îl redirecționează către alt punct final creează un dialog îndreptat spre o rețea pe care apelatul nu o poate atinge. Setarea rewrite_contact=yes pe punctul final PJSIP face PBX-ul să înlocuiască adresa sursă observată, iar aceasta este adesea diferența dintre un apel care sună și unul care expiră.
Ce oferă INVITE și cine îl poate folosi
Un INVITE cu corp SDP propune unde vrea apelantul să primească media: o adresă, un port și o listă de codecuri. Apelatul răspunde cu propria adresă și propriul port, apoi fiecare parte trimite RTP către ce a propus cealaltă. Dacă apelantul a propus o adresă 192.168.x.x care există doar în rețeaua sa de acasă, apelatul nu are unde trimite audio, oricât de curată ar fi fost semnalizarea. Mascarea rescrie antetele IP când pachetele părăsesc un router, dar nu rescrie niciodată textul din interiorul unui corp SDP.
Această lipsă explică apelul unidirecțional clasic: semnalizarea funcționează pentru că ambele puncte finale ajung la PBX, iar audio-ul eșuează pentru că unui punct final i s-a spus să trimită către o adresă care există doar în spatele altui NAT.
| Path | Who picks the address | Typical failure |
|---|---|---|
| REGISTER | Softphone, rewritten by the registrar if configured | Binding expires or points at a private address |
| INVITE and SDP | Each endpoint in its own offer or answer | Offer names a media address nobody can route to |
| RTP | PBX relay policy or the two endpoints | Port range blocked, or no return path |
Cine transportă audio-ul este o alegere de configurare
Semnalizarea și media sunt roluri separate. Un proxy poate rămâne pe calea semnalizării pentru un întreg apel și nu atinge niciodată un singur pachet RTP. Dacă PBX-ul devine releu media depinde de configurare, nu de prezența unui tunel.
Cu media directă, punctele finale schimbă ele însele RTP, ceea ce funcționează bine într-un LAN și prost când o parte stă în spatele unui interval îngust de porturi.
Setarea direct_media=no împinge PBX-ul pe calea media, astfel încât ambele picioare să se termine pe o adresă pe care o controlează, schimbând lățime de bandă și CPU pentru adresare previzibilă. Când retransmite, PBX-ul tot trebuie să anunțe o adresă accesibilă. Pe un gazdă cu mai multe rețele, external_media_address și external_signaling_address din pjsip.conf decid ce apare în SDP și în antetele Via. Dacă le lăsați nesetate, PBX-ul poate oferi adresa sa LAN unui apelant a cărui singură rută este partea îndepărtată a tunelului.
Urmăriți fiecare direcție înainte de a atinge setările
Începeți cu tabelul de socketuri de pe PBX în timp ce un apel este activ: ss -uanp | grep -E '5060|10000' arată dacă porturile RTP sunt legate și ce adresă locală folosesc. Dacă nimic nu este legat în intervalul media, releul nu este implicat și punctele finale vorbesc direct. Apoi capturați pe partea softphone cu tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap. Pachetele ieșite fără pachete intrate îngustează problema la calea de întoarcere sau la adresa pe care partea îndepărtată a fost instruuită să o folosească, iar o captură goală înseamnă că media nu a ajuns niciodată la interfața tunelului. O captură de semnalizare cu sngrep răspunde celeilalte jumătăți arătând linia de conexiune SDP așa cum a fost trimisă.
Comparați adresa din acea linie de conexiune cu adresa către care partea îndepărtată poate într-adevăr să ruteze. Această singură comparație rezolvă majoritatea rapoartelor de audio unidirecțional mai repede decât orice revizuire a configurației.
Criptarea se oprește la marginea tunelului
SIP peste TLS protejează saltul de semnalizare pentru care a fost configurat, SRTP protejează media când ambele capete o negociază, iar tunelul protejează traficul între propriile puncte finale. Niciunul nu le acordă pe celelalte. Un apel criptat în interiorul tunelului poate părăsi gateway-ul în text clar spre PBX, iar aceasta este o decizie de proiectare, nu un defect.
Înainte de a închide tichetul, confirmați trei lucruri în ordine: înregistrarea este proaspătă, SDP-ul poartă o adresă la care partea îndepărtată poate ajunge și pachetele curg în ambele sensuri pe porturile media. Dacă vreuna dintre ele este falsă, tunelul nu este locul problemei. Remediați calea care a eșuat, apoi rulați din nou aceeași captură pentru a confirma schimbarea. Păstrarea capturilor de dinainte și de după face din următorul raport unidirecțional o verificare de cinci minute în loc de o după-amiază întreagă.