Kāpēc SIP zvans reģistrējas caur VPN, bet nesūta skaņu
Reģistrācija un skaņa iet pa dažādiem ceļiem. Izsekojiet vienu zvanu cauri tunelim, lai redzētu, kādas adreses PBX var izmantot un kur RTP patiešām apstājas.
Veiksmīga reģistrācija gandrīz neko nepasaka par skaņu. Programmatūras tālrunis var stundām ilgi uzturēt derīgu saistījumu ar biroja PBX un tomēr piegādāt klusumu. Tunelis pārvadā tikai tās paketes, ko kāds apzināti tajā sūta, un zvans izmanto trīs atsevišķus ceļus: saistījumu, dialoga izveidi un RTP plūsmu. Kad tos atdala, kļūme krīt uz vienu ceļu, nevis uz vārdu VPN.
Iedomājieties klēpjdatoru mājas Wi-Fi tīklā, kas caur apstiprinātu tuneli zvana biroja iekšējo numuru. PBX autentificē lietotāju, pieņem REGISTER, un iekšējais numurs parādās kā pieejams, tomēr zvans savienojas ar pilnīgu klusumu vienā virzienā.
Reģistrācija saista kontaktu, nevis multivides ceļu
REGISTER pieprasījums lūdz reģistratoru saglabāt atbilstību starp ieraksta adresi un vienu vai vairākiem kontakta URI. Šī atbilstība atbild uz šauru jautājumu, kur tieši tagad jāsūta jauns dialogs. Tā neko nesaka par to, kur pieder multivide, un pieņemta reģistrācija nepierāda, ka vēlāks INVITE nes sasniedzamu multivides adresi. Reģistrācijas arī beidzas pēc taimera, tāpēc tālrunis, kas pārtrauc atjaunošanu, zaudē ienākošos zvanus, kamēr tā tunelis vēl izskatās vesels. Vērojiet kontakta derīguma beigas, nevis tuneļa stāvokli.
Kad programmatūras tālrunis atrodas aiz tuneļa, kontakta galvene var saturēt privātu adresi. PBX, kas to pārsūta uz citu galapunktu, izveido dialogu, kas vērsts uz tīklu, kuru izsaucamā puse nevar sasniegt. Iestatot rewrite_contact=yes PJSIP galapunktā, PBX aizstāj novēroto avota adresi, un tā bieži ir atšķirība starp zvanu un taimautu.
Ko piedāvā INVITE un kas to var izmantot
INVITE ar SDP pamattekstu piedāvā, kur zvanītājs vēlas saņemt multividi: adresi, portu un kodeku sarakstu. Izsaucamā puse atbild ar savu adresi un portu, un pēc tam katra puse sūta RTP uz to, ko otra piedāvāja. Ja zvanītājs piedāvāja 192.168.x.x adresi, kas pastāv tikai viņa mājas tīklā, izsaucamajai pusei nav kur sūtīt skaņu, lai cik tīra būtu signalizācija. Maskēšana pārraksta IP galvenes, kad paketes atstāj maršrutētāju, bet tā nekad nepārraksta tekstu SDP pamattekstā.
Šī plaisa izskaidro klasisko vienvirziena zvanu: signalizācija darbojas, jo abi galapunkti sasniedz PBX, un skaņa neizdodas, jo vienam galapunktam tika pateikts sūtīt uz adresi, kas pastāv tikai aiz cita 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 |
Kas pārvadā skaņu, ir konfigurācijas izvēle
Signalizācija un multivide ir atsevišķas lomas. Starpprogramma var visu zvanu palikt signalizācijas ceļā un nekad neaizskart nevienu RTP paketi. Vai PBX kļūs par multivides retranslatoru, ir atkarīgs no konfigurācijas, nevis no tuneļa esamības.
Ar tiešu multividi galapunkti paši apmainās ar RTP, kas labi darbojas vienā LAN un slikti, ja viena puse atrodas aiz šaura portu diapazona.
Iestatot direct_media=no, PBX tiek iespiests multivides ceļā, lai abas kājas beigtos tā kontrolētā adresē, apmainot joslas platumu un procesoru pret paredzamu adresāciju. Kad tas retranslē, PBX joprojām ir jāpaziņo sasniedzama adrese. Daudztīkla resursdatorā external_media_address un external_signaling_address failā pjsip.conf nosaka, kas parādās SDP un Via galvenēs. Atstājiet tos neiestatītus, un PBX var piedāvāt savu LAN adresi zvanītājam, kura vienīgais ceļš ir tuneļa tālā puse.
Izsekojiet katram virzienam pirms iestatījumu aizskaršanas
Sāciet ar PBX ligzdu tabulu, kamēr zvans ir aktīvs: ss -uanp | grep -E '5060|10000' parāda, vai RTP porti ir piesaistīti un kuru vietējo adresi tie izmanto. Ja multivides diapazonā nekas nav piesaistīts, retranslators nav iesaistīts un galapunkti runā tieši. Pēc tam ierakstiet programmatūras tālruņa pusē ar tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap. Izejošās paketes bez ienākošajām sašaurina problēmu līdz atgriešanās ceļam vai adresei, kas tālajai pusei tika likts izmantot, un tukšs ieraksts nozīmē, ka multivide vispār nesasniedza tuneļa saskarni. Signalizācijas ieraksts ar sngrep atbild uz otru pusi, parādot SDP savienojuma rindu tādu, kāda tā tika nosūtīta.
Salīdziniet adresi šajā savienojuma rindā ar adresi, uz kuru tālā puse patiešām var maršrutēt. Šis viens salīdzinājums atrisina lielāko daļu vienvirziena skaņas ziņojumu ātrāk nekā jebkura konfigurācijas pārbaude.
Šifrēšana apstājas pie tuneļa malas
SIP virs TLS aizsargā signalizācijas lēcienu, kuram tas tika konfigurēts, SRTP aizsargā multividi, kad abas puses par to vienojas, un tunelis aizsargā satiksmi starp saviem galapunktiem. Neviens no tiem nedod pārējos. Zvans, kas šifrēts tuneļa iekšienē, var atstāt vārteju atklātā tekstā pretī PBX, un tas ir dizaina lēmums, nevis defekts.
Pirms biļetes aizvēršanas secīgi apstipriniet trīs lietas: reģistrācija ir svaiga, SDP satur adresi, kuru tālā puse var sasniegt, un paketes plūst abos virzienos pa multivides portiem. Ja kaut kas no tā ir nepatiess, tunelis nav problēmas vieta. Izlabojiet neizdevušos ceļu un pēc tam atkārtojiet to pašu ierakstu, lai apstiprinātu izmaiņas. Ierakstu pirms un pēc saglabāšana pārvērš nākamo vienvirziena ziņojumu piecu minūšu pārbaudē, nevis veselā pēcpusdienā.