Pse një thirrje SIP regjistrohet përmes VPN-së por nuk dërgon audio
Regjistrimi dhe audioja ndjekin rrugë të ndryshme. Ndiqui një thirrje përmes tunelit për të parë cilat adresa mund të përdorë PBX-ja dhe ku ndalon në të vërtetë RTP.
Një regjistrim i suksesshëm nuk thotë pothuajse asgjë për audion. Një softphone mund të mbajë për orë të tëra një lidhje të vlefshme me PBX-në e zyrës dhe gjithsesi të dërgojë heshtje. Tuneli mbart vetëm paketat që dikush i dërgon qëllimisht brenda tij, dhe një thirrje përdor tre rrugë të veçanta: lidhjen, vendosjen e dialogut dhe rrjedhën RTP. Sapo t'i ndani, defekti bie mbi një rrugë dhe jo mbi fjalën VPN.
Imagjinoni një laptop në Wi-Fi-n e shtëpisë që telefonon një shtojcë të zyrës përmes një tuneli të miratuar. PBX-ja vërteton përdoruesin, pranon REGISTER, dhe shtojca shfaqet si e disponueshme, por thirrja lidhet me heshtje të plotë në një drejtim.
Regjistrimi lidh një kontakt, jo një rrugë mediash
Një kërkesë REGISTER i kërkon regjistruesit të ruajë një përputhje midis një adrese regjistri dhe një ose më shumë URI kontakti. Kjo përputhje përgjigjet një pyetje të ngushtë: ku duhet dërguar tani një dialog i ri. Nuk thotë asgjë për atë se ku bëjnë pjesë mediat, dhe një regjistrim i pranuar nuk provon që një INVITE i mëvonshëm mbart një adresë mediash të arritshme. Regjistrimet skadojnë gjithashtu me një kohëmatës, kështu që një telefon që ndalon rifreskimin humbet thirrjet hyrëse ndërsa tuneli i tij ende duket i shëndetshëm. Vëzhgoni skadimin e kontaktit dhe jo statusin e tunelit.
Kur softphone-i ndodhet pas tunelit, koka e kontaktit mund të mbartë një adresë private. Një PBX që e përcjell te një pikë tjetër fundore krijon një dialog të drejtuar drejt një rrjeti që i thirruri nuk mund ta arrijë. Caktimi i rewrite_contact=yes në pikën fundore PJSIP bën që PBX-ja të zëvendësojë adresën burimore që ka vëzhguar, dhe kjo është shpesh dallimi midis një zile dhe një skadimi kohe.
Çfarë ofron INVITE dhe kush mund ta përdorë
Një INVITE me trup SDP propozon ku telefonuesi dëshiron të marrë media: një adresë, një port dhe një listë kodekësh. I thirruri përgjigjet me adresën dhe portin e vet, dhe më pas secila palë dërgon RTP atje ku propozoi tjetra. Nëse telefonuesi propozoi një adresë 192.168.x.x që ekziston vetëm brenda rrjetit të tij të shtëpisë, i thirruri nuk ka ku të dërgojë audio, sado e pastër të ketë qenë sinjalizimi. Maskimi rishkruan kokët IP kur paketat largohen nga një ruter, por nuk rishkruan kurrë tekstin brenda një trupi SDP.
Ky boshllëk shpjegon thirrjen klasike njëdrejtimëshe: sinjalizimi funksionon sepse të dyja pikat fundore arrijnë PBX-në, dhe audioja dështon sepse njërës pikë fundore iu tha të dërgojë në një adresë që ekziston vetëm pas një NAT tjetër.
| 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 |
Kush e mbart audion është një zgjedhje konfigurimi
Sinjalizimi dhe mediat janë role të ndara. Një proxy mund të qëndrojë në rrugën e sinjalizimit për një thirrje të tërë dhe të mos prekë kurrë asnjë paketë RTP. Nëse PBX-ja bëhet përcjellëse mediash varet nga konfigurimi, jo nga prania e një tuneli.
Me media të drejtpërdrejta pikat fundore shkëmbejnë vetë RTP-në, gjë që funksionon mirë në një LAN dhe keq kur njëra palë ndodhet pas një diapazoni të ngushtë portesh.
Caktimi i direct_media=no e shtyn PBX-në në rrugën e mediave, kështu që të dyja këmbët përfundojnë në një adresë që ajo kontrollon, duke shkëmbyer gjerësinë e brezit dhe CPU-në për adresim të parashikueshëm. Kur përcjell, PBX-ja duhet gjithsesi të shpallë një adresë të arritshme. Në një host me shumë rrjete, external_media_address dhe external_signaling_address në pjsip.conf vendosin çfarë shfaqet në SDP dhe në kokët Via. Nëse i lini të pacaktuara, PBX-ja mund t'i ofrojë adresën e saj LAN një telefonuesi, rruga e vetme e të cilit është ana e largët e tunelit.
Ndiqui çdo drejtim përpara se të prekni cilësimet
Filloni me tabelën e soketëve në PBX ndërsa një thirrje është aktive: ss -uanp | grep -E '5060|10000' tregon nëse portet RTP janë të lidhura dhe cilën adresë lokale përdorin. Nëse asgjë nuk është e lidhur në diapazonin e mediave, përcjellësi nuk është aktiv dhe pikat fundore flasin drejtpërdrejt. Më pas kapni në anën e softphone-it me tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap. Paketat dalëse pa paketa hyrëse e ngushtojnë problemin te rruga e kthimit ose te adresa që palës së largët iu tha të përdorë, dhe një kapje e zbrazët do të thotë që mediat nuk arritën kurrë ndërfaqen e tunelit. Një kapje sinjalizimi me sngrep i përgjigjet gjysmës tjetër duke treguar rreshtin e lidhjes SDP siç u dërgua.
Krahasoni adresën në atë rresht lidhjeje me adresën drejt së cilës pala e largët mund vërtet të rrugëzojë. Ky krahasim i vetëm zgjidh shumicën e raporteve të audios njëdrejtimëshe më shpejt se çdo rishikim konfigurimi.
Kriptimi ndalon në skajin e tunelit
SIP mbi TLS mbron hopin e sinjalizimit për të cilin është konfiguruar, SRTP mbron mediat kur të dy skajet bien dakord, dhe tuneli mbron trafikun midis pikave të tij fundore. Asnjë prej tyre nuk i jep të tjerat. Një thirrje e kriptuar brenda tunelit mund të dalë nga porta në tekst të qartë drejt PBX-së, dhe ky është një vendim dizajni, jo një defekt.
Përpara se të mbyllni biletën, konfirmoni tre gjëra sipas radhës: regjistrimi është i freskët, SDP-ja mbart një adresë që pala e largët mund ta arrijë, dhe paketat rrjedhin në të dy drejtimet në portet e mediave. Nëse njëra prej tyre është e gabuar, tuneli nuk është vendi ku banon problemi. Rregulloni rrugën që dështoi, pastaj rikandoni të njëjtën kapje për të konfirmuar ndryshimin. Ruajtja e kapjeve para dhe pas e kthen raportin e ardhshëm njëdrejtimësh në një kontroll pesëminutësh në vend të një pasditeje të tërë.