Miks SIP-kõne registreerub VPN-i kaudu, kuid ei saada heli
Registreerimine ja heli kulgevad eri teid pidi. Jälgige üht kõnet tunnelist läbi, et näha, milliseid aadresse saab PBX kasutada ja kus RTP tegelikult peatub.
Edukas registreerimine ei ütle heli kohta peaaegu midagi. Softphone võib tunde hoida kehtivat sidet kontori PBX-iga ja edastada ikkagi vaikust. Tunnel kannab ainult neid pakette, mille keegi sinna teadlikult saadab, ja kõne kasutab kolme eraldi teed: sidumine, dialoogi loomine ja RTP voog. Kui need lahku lööte, langeb viga ühele teele, mitte sõnale VPN.
Kujutage ette sülearvutit kodu-WiFi-s, mis valib kõneks kontori laienduse heakskiidetud tunneli kaudu. PBX autendib kasutaja, võtab REGISTER-i vastu ja laiendus kuvatakse saadaolevana, kuid kõne ühendub ühes suunas täieliku vaikusega.
Registreerimine seob kontakti, mitte meedia tee
REGISTER-päring palub registraatoril salvestada vastavuse aadressi-kirje ja ühe või mitme kontakt-URI vahel. See vastavus vastab kitsale küsimusele, kuhu uus dialoog praegu saata. See ei ütle midagi selle kohta, kuhu meedia kuulub, ja vastuvõetud registreerimine ei tõesta, et hilisem INVITE kannab kättesaadavat meedia-aadressi. Registreerimised aeguvad ka taimeri järgi, nii et telefon, mis lõpetab värskendamise, kaotab sissetulevad kõned, samal ajal kui selle tunnel näib endiselt terve. Jälgige kontakti aegumist, mitte tunneli olekut.
Kui softphone asub tunneli taga, võib kontakti päis kanda privaatset aadressi. PBX, mis edastab selle teisele lõpp-punktile, loob dialoogi, mis on suunatud võrku, kuhu kutsutud ei pääse. Suvandi rewrite_contact=yes seadistamine PJSIP lõpp-punktis paneb PBX-i asendama täheldatud lähteaadressi, ja see on sageli helina ja ajalõpu vahe.
Mida INVITE pakub ja kes saab seda kasutada
SDP kehaga INVITE pakub, kus soovib helistaja meediat vastu võtta: aadress, port ja koodekite loend. Kutsutud vastab oma aadressi ja pordiga ning seejärel saadab kumbki pool RTP sellele, mida teine pakkus. Kui helistaja pakkus aadressi 192.168.x.x, mis eksisteerib ainult tema koduvõrgus, ei ole kutsutul kuhugi heli saata, ükskõik kui puhas oli signalisatsioon. Maskeerimine kirjutab IP-päiseid ümber, kui paketid ruuterist väljuvad, kuid ei kirjuta kunagi ümber teksti SDP keha sees.
See lünk selgitab klassikalist ühesuunalist kõnet: signalisatsioon töötab, sest mõlemad lõpp-punktid pääsevad PBX-i, ja heli ebaõnnestub, sest ühele lõpp-punktile öeldi saata aadressile, mis eksisteerib ainult teise NAT-i taga.
| 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 |
Kes heli kannab, on konfiguratsiooni valik
Signalisatsioon ja meedia on eraldi rollid. Puhverserver võib kogu kõne vältel jääda signalisatsiooni teele ega puuduta kunagi ühtki RTP-paketti. Kas PBX-ist saab meediarelee, sõltub konfiguratsioonist, mitte tunneli olemasolust.
Otsese meediaga vahetavad lõpp-punktid RTP-d ise, mis töötab ühes LAN-is hästi ja halvasti siis, kui üks pool asub kitsa pordivahemiku taga.
Suvandi direct_media=no seadistamine surub PBX-i meedia teele, nii et mõlemad harud lõpevad aadressil, mida ta kontrollib, vahetades ribalaiuse ja protsessori prognoositava adresseerimise vastu. Edastades peab PBX ikkagi teatama kättesaadava aadressi. Mitme võrguliidesega hostis otsustavad external_media_address ja external_signaling_address failis pjsip.conf, mis ilmub SDP-s ja Via-päistes. Kui jätate need seadistamata, võib PBX pakkuda oma LAN-aadressi helistajale, kelle ainus tee on tunneli kaugem pool.
Jälgige mõlemat suunda enne seadete puutumist
Alustage PBX-i soklite tabelist, kui kõne on aktiivne: ss -uanp | grep -E '5060|10000' näitab, kas RTP-pordid on seotud ja millist kohalikku aadressi need kasutavad. Kui meediavahemikus pole midagi seotud, ei ole relee rakendatud ja lõpp-punktid räägivad otse. Seejärel jäädvustage softphone'i poolel käsuga tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap. Väljuvad paketid ilma sissetulevateta kitsendavad probleemi tagasiteele või aadressile, mida kaugemale poolele kasutada öeldi, ja tühi jäädvustus tähendab, et meedia ei jõudnud tunneliliideseni üldse. Signalisatsiooni jäädvustus käsuga sngrep vastab teisele poolele, näidates SDP ühendusrida sellisena, nagu see saadeti.
Võrrelge selles ühendusreas olevat aadressi aadressiga, kuhu kaugem pool suudab tegelikult marsruutida. See üks võrdlus lahendab enamiku ühesuunalise heli raportitest kiiremini kui ükski konfiguratsiooni ülevaatus.
Krüpteerimine lõpeb tunneli servas
SIP üle TLS-i kaitseb signalisatsioonihüpet, mille jaoks see seadistati, SRTP kaitseb meediat, kui mõlemad pooled selle kokku lepivad, ja tunnel kaitseb liiklust oma enda lõpp-punktide vahel. Ükski neist ei anna teisi. Tunneli sees krüpteeritud kõne võib lahkuda lüüsist PBX-i suunas avatekstina, ja see on disainiotsus, mitte viga.
Enne pileti sulgemist kinnitage kolm asja järjekorras: registreerimine on värske, SDP kannab aadressi, kuhu kaugem pool pääseb, ja paketid liiguvad meediaportidel mõlemas suunas. Kui mõni neist on vale, ei asu probleem tunnelis. Parandage tee, mis ebaõnnestus, ja käivitage seejärel sama jäädvustus uuesti, et muudatust kinnitada. Enne ja pärast tehtud jäädvustuste hoidmine muudab järgmise ühesuunalise raporti viieminutiliseks kontrolliks tervikliku pärastlõuna asemel.