Miért regisztrál egy SIP-hívás VPN-en át, de nem küld hangot
A regisztráció és a hang különböző útvonalakon halad. Kövessen végig egy hívást az alagúton, hogy lássa, mely címeket használhat a PBX, és hol áll meg valójában az RTP.
A sikeres regisztráció szinte semmit sem mond a hangról. Egy softphone órákig tarthat fenn érvényes kötést az irodai PBX-hez, és mégis csendet szállíthat. Az alagút csak azokat a csomagokat viszi, amelyeket valaki szándékosan bele küld, és egy hívás három külön útvonalat használ: a kötést, a párbeszéd felépítését és az RTP-folyamot. Ha ezeket szétválasztja, a hiba egy útvonalra esik, nem a VPN szóra.
Képzeljen el egy laptopot az otthoni Wi-Fi-n, amely jóváhagyott alagúton hív egy irodai melléket. A PBX hitelesíti a felhasználót, elfogadja a REGISTER-t, és a mellék elérhetőnek látszik, a hívás mégis teljes csenddel kapcsolódik az egyik irányban.
A regisztráció kapcsolatot köt, nem médiaútvonalat
A REGISTER kérés arra kéri a regisztrátort, hogy tároljon leképezést egy rekordcím és egy vagy több kapcsolat-URI között. Ez a leképezés egy szűk kérdésre válaszol: hová kell most elküldeni egy új párbeszédet. Semmit sem mond arról, hová tartozik a média, és az elfogadott regisztráció nem bizonyítja, hogy egy későbbi INVITE elérhető média-címet hordoz. A regisztrációk időzítővel is lejárnak, így az a telefon, amely abbahagyja a frissítést, elveszíti a bejövő hívásokat, miközben az alagútja még egészségesnek látszik. A kapcsolat lejáratát figyelje, ne az alagút állapotát.
Amikor a softphone az alagút mögött van, a kapcsolat fejléc privát címet hordozhat. Az a PBX, amely továbbítja egy másik végpontnak, olyan hálózatra irányuló párbeszédet hoz létre, amelyet a hívott fél nem ér el. A rewrite_contact=yes beállítása a PJSIP végponton arra készteti a PBX-et, hogy a megfigyelt forráscímet helyettesítse, és ez gyakran a csengés és az időtúllépés közötti különbség.
Mit kínál az INVITE, és ki használhatja
Az SDP-törzset tartalmazó INVITE javaslatot tesz arra, hol akar a hívó médiát fogadni: cím, port és kodeklista. A hívott fél a saját címével és portjával válaszol, majd mindkét oldal RTP-t küld oda, amit a másik javasolt. Ha a hívó olyan 192.168.x.x címet javasolt, amely csak az otthoni hálózatában létezik, a hívott félnek nincs hová hangot küldenie, bármilyen tiszta is volt a jelzés. A maszkolás átírja az IP-fejléceket, amikor a csomagok elhagyják az útválasztót, de soha nem írja át az SDP-törzsön belüli szöveget.
Ez a rés magyarázza a klasszikus egyirányú hívást: a jelzés azért működik, mert mindkét végpont eléri a PBX-et, a hang pedig azért hiúsul meg, mert az egyik végpontnak olyan címre kellett küldenie, amely csak egy másik NAT mögött létezik.
| 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 |
Hogy ki viszi a hangot, konfigurációs döntés
A jelzés és a média külön szerepek. Egy proxy az egész hívás alatt a jelzési útvonalon maradhat, és soha nem érint egyetlen RTP-csomagot sem. Az, hogy a PBX média-relévé válik-e, a konfigurációtól függ, nem az alagút jelenlététől.
Közvetlen média esetén a végpontok maguk cserélik az RTP-t, ami egy LAN-on jól működik, és rosszul, ha az egyik oldal szűk porttartomány mögött van.
A direct_media=no beállítása a médiaútvonalra kényszeríti a PBX-et, hogy mindkét szár az általa vezérelt címen végződjön, sávszélességet és processzort cserélve a kiszámítható címzésért. Amikor továbbít, a PBX-nek még mindig elérhető címet kell hirdetnie. Több hálózatú gazdagépen a external_media_address és a external_signaling_address a pjsip.conf fájlban dönti el, mi jelenik meg az SDP-ben és a Via-fejlécekben. Ha beállítatlanul hagyja őket, a PBX az alagút túlsó oldalát egyetlen útvonalként használó hívónak kínálhatja a LAN-címét.
Mindkét irányt kövesse, mielőtt a beállításokhoz nyúl
Kezdje a PBX socket-táblájával, amíg a hívás fennáll: a ss -uanp | grep -E '5060|10000' megmutatja, hogy az RTP-portok kötöttek-e, és melyik helyi címet használják. Ha a média tartományban semmi sincs kötve, a relé nem vesz részt, és a végpontok közvetlenül beszélnek. Ezután rögzítsen a softphone oldalán a tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap segítségével. A kimenő csomagok bejövő csomagok nélkül a visszaútra vagy arra a címre szűkítik a problémát, amelyet a túlsó félnek mondtak használatra, az üres rögzítés pedig azt jelenti, hogy a média soha nem érte el az alagút interfészét. A sngrep segítségével készült jelzésrögzítés a másik felére válaszol azzal, hogy megmutatja az SDP-kapcsolati sort úgy, ahogy elküldték.
Hasonlítsa össze az adott kapcsolati sorban lévő címet azzal a címmel, ahová a túlsó fél valóban irányíthat. Ez az egyetlen összehasonlítás gyorsabban megoldja a legtöbb egyirányú hangjelentést, mint bármely konfigurációs átvizsgálás.
A titkosítás az alagút szélén megáll
A TLS feletti SIP védi a jelzési ugrást, amelyre beállították, az SRTP védi a médiát, amikor mindkét fél megtárgyalja, az alagút pedig a saját végpontjai közötti forgalmat védi. Ezek egyike sem adja a többit. Az alagúton belül titkosított hívás a gateway-től a PBX felé sima szövegben léphet ki, és ez tervezési döntés, nem hiba.
A jegy lezárása előtt három dolgot igazoljon sorrendben: a regisztráció friss, az SDP olyan címet hordoz, amelyet a túlsó fél elér, és a csomagok a médiaportokon mindkét irányban folynak. Ha ezek bármelyike hamis, a probléma nem az alagútban van. Javítsa ki a meghiúsult útvonalat, majd futtassa újra ugyanazt a rögzítést a változás megerősítéséhez. Az előtti és utáni rögzítések megtartása a következő egyirányú jelentést ötperces ellenőrzéssé teszi egy egész délután helyett.