Bakit nagrehistro ang tawag na SIP sa VPN pero walang naipadalang audio
Magkaibang landas ang rehistro at audio. Subaybayan ang isang tawag sa lagusan upang makita kung aling mga address ang magagamit ng PBX at saan talaga humihinto ang RTP.
Ang matagumpay na rehistro ay halos walang sinasabi tungkol sa audio. Ang softphone ay maaaring magpanatili ng wastong pagkakabit sa PBX ng opisina nang maraming oras at maghatid pa rin ng katahimikan. Ang lagusan ay nagdadala lamang ng mga packet na sadyang ipinapadala ng isang tao papasok dito, at ang isang tawag ay gumagamit ng tatlong magkahiwalay na landas: pagkakabit, paghahanda ng diyalogo at ang daloy ng RTP. Kapag pinaghiwalay mo ang mga ito, bumabagsak ang kabiguan sa isang landas at hindi sa salitang VPN.
Isipin ang isang laptop sa Wi-Fi ng bahay na tumatawag sa extension ng opisina sa pamamagitan ng aprubadong lagusan. Ina-authenticate ng PBX ang user, tinatanggap ang REGISTER, at lumalabas na available ang extension, ngunit kumokonekta ang tawag na may lubos na katahimikan sa isang direksyon.
Ang rehistro ay nagbibigkis ng contact, hindi ng landas ng media
Ang kahilingang REGISTER ay humihiling sa registrar na mag-imbak ng pagmamapa sa pagitan ng address-of-record at isa o higit pang contact URI. Sinasagot ng pagmamapa iyon ang makitid na tanong kung saan dapat ipadala ang bagong diyalogo ngayon. Wala itong sinasabi tungkol sa kung saan nabibilang ang media, at ang tinanggap na rehistro ay hindi nagpapatunay na ang susunod na INVITE ay may dalang maaabot na address ng media. Nag-expire din ang mga rehistro sa isang timer, kaya ang teleponong tumigil sa pag-refresh ay nawawalan ng mga papasok na tawag habang mukhang malusog pa ang lagusan nito. Bantayan ang pag-expire ng contact at hindi ang estado ng lagusan.
Kapag ang softphone ay nasa likod ng lagusan, ang header ng contact ay maaaring may dalang pribadong address. Ang PBX na nagpapasa nito sa ibang endpoint ay gumagawa ng diyalogong nakaturo sa network na hindi maabot ng tinawagan. Ang pagtatakda ng rewrite_contact=yes sa PJSIP endpoint ay nagpapalit sa naobserbahang source address ng PBX, at ito ang madalas na pagkakaiba ng tugtog at timeout.
Ano ang iniaalok ng INVITE at sino ang makakagamit nito
Ang INVITE na may SDP body ay nagmumungkahi kung saan gustong tumanggap ng media ng tumatawag: isang address, isang port at isang listahan ng codec. Sumasagot ang tinawagan gamit ang sarili nitong address at port, at pagkatapos ay nagpapadala ang bawat panig ng RTP sa kung ano ang iminungkahi ng kabila. Kung ang tumatawag ay nagmungkahi ng address na 192.168.x.x na umiiral lamang sa loob ng kanyang network sa bahay, wala nang mapagpadalhan ng audio ang tinawagan, gaano man kalinis ang signaling. Ang masking ay nagsusulat muli ng mga IP header kapag umaalis ang mga packet sa router, ngunit hindi kailanman nagsusulat muli ng teksto sa loob ng SDP body.
Ang puwang na iyon ang nagpapaliwanag sa klasikong one-way na tawag: gumagana ang signaling dahil naaabot ng dalawang endpoint ang PBX, at nabigo ang audio dahil sinabihan ang isang endpoint na magpadala sa address na umiiral lamang sa likod ng ibang 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 |
Kung sino ang nagdadala ng audio ay pagpipilian sa configuration
Magkahiwalay na tungkulin ang signaling at media. Ang proxy ay maaaring manatili sa landas ng signaling sa buong tawag at hindi kailanman hahawak sa kahit isang RTP packet. Kung magiging media relay ang PBX ay nakasalalay sa configuration, hindi sa pagkakaroon ng lagusan.
Sa direktang media, ang mga endpoint mismo ang nagpapalitan ng RTP, na gumagana nang maayos sa isang LAN at masama kapag ang isang panig ay nasa likod ng makitid na hanay ng port.
Ang pagtatakda ng direct_media=no ay nagtutulak sa PBX papasok sa landas ng media upang ang dalawang binti ay magtapos sa address na kontrolado nito, kapalit ng bandwidth at CPU para sa mahuhulaang addressing. Kapag nagre-relay, kailangan pa ring mag-anunsyo ng maaabot na address ang PBX. Sa host na may maraming network, ang external_media_address at external_signaling_address sa pjsip.conf ang nagtatakda kung ano ang lalabas sa SDP at sa Via header. Kung iiwan mong hindi nakatakda, maaaring ialok ng PBX ang LAN address nito sa tumatawag na ang tanging landas ay ang malayong bahagi ng lagusan.
Subaybayan ang bawat direksyon bago hawakan ang mga setting
Magsimula sa socket table sa PBX habang aktibo ang tawag: ipinapakita ng ss -uanp | grep -E '5060|10000' kung nakakabit ang mga RTP port at kung aling lokal na address ang ginagamit. Kung wala namang nakakabit sa hanay ng media, hindi kasali ang relay at direktang nag-uusap ang mga endpoint. Pagkatapos ay kunan ng capture sa panig ng softphone gamit ang tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap. Ang mga papalabas na packet na walang papasok ay nagpapaliit ng problema sa return path o sa address na sinabihan sa malayong panig na gamitin, at ang walang laman na capture ay nangangahulugang hindi kailanman naabot ng media ang interface ng lagusan. Ang capture ng signaling gamit ang sngrep ay sumasagot sa kabilang kalahati sa pamamagitan ng pagpapakita ng SDP connection line gaya ng ipinadala.
Ihambing ang address sa connection line na iyon sa address na tunay na mararating ng malayong panig. Ang nag-iisang paghahambing na iyon ay lumulutas sa karamihan ng ulat ng one-way na audio nang mas mabilis kaysa sa anumang pagsusuri ng configuration.
Humihinto ang encryption sa gilid ng lagusan
Pinoprotektahan ng SIP sa TLS ang signaling hop na inilaan para dito, pinoprotektahan ng SRTP ang media kapag nagkasundo ang dalawang dulo, at pinoprotektahan ng lagusan ang trapiko sa pagitan ng sarili nitong mga endpoint. Wala sa mga ito ang nagbibigay ng iba pa. Ang tawag na naka-encrypt sa loob ng lagusan ay maaaring lumabas sa gateway nang plaintext patungo sa PBX, at iyon ay desisyon sa disenyo, hindi depekto.
Bago isara ang ticket, tiyakin ang tatlong bagay sa pagkakasunod-sunod: sariwa ang rehistro, may dalang address ang SDP na maaabot ng malayong panig, at dumadaloy ang mga packet sa dalawang direksyon sa mga port ng media. Kung alinman sa mga ito ay mali, wala sa lagusan ang problema. Ayusin ang landas na nabigo, pagkatapos ay patakbuhin muli ang parehong capture upang kumpirmahin ang pagbabago. Ang pag-iingat ng mga capture bago at pagkatapos ay ginagawang limang minutong pagsusuri ang susunod na ulat ng one-way kaysa sa isang buong hapon.