Kial SIP-voko registriĝas tra VPN sed sendas neniun sonon
Registrado kaj sono sekvas malsamajn vojojn. Spuru unu vokon tra la tunelo por vidi, kiujn adresojn la PBX povas uzi kaj kie RTP efektive haltas.
Sukcesa registrado preskaŭ nenion diras pri sono. Softfono povas teni validan ligon al la oficeja PBX dum horoj kaj tamen transdoni silenton. La tunelo portas nur tiujn pakojn, kiujn iu konscie en ĝin sendas, kaj voko uzas tri apartajn vojojn: ligo, dialog-konstruo kaj la RTP-fluo. Post kiam vi disigos ilin, la paneo falas sur unu vojon anstataŭ sur la vorton VPN.
Imagu tekkomputilon en hejma Wi-Fi, kiu vokas oficejan etendaĵon tra aprobita tunelo. La PBX aŭtentikigas la uzanton, akceptas la REGISTER, kaj la etendaĵo montriĝas disponebla, tamen la voko konektiĝas kun morta silento en unu direkto.
Registrado ligas kontakton, ne mediovojo
REGISTER-peto petas la registrilon konservi mapadon inter adreso-de-rikordo kaj unu aŭ pluraj kontaktaj URI-oj. Tiu mapado respondas mallarĝan demandon pri tio, kien nova dialogo sendiĝu ĝuste nun. Ĝi diras nenion pri tio, kie medioj apartenas, kaj akceptita registrado ne pruvas, ke posta INVITE portas atingeblan median adreson. Registradoj ankaŭ eksvalidiĝas laŭ temponombrilo, do telefono, kiu ĉesas refreŝigi, perdas envenantajn vokojn dum ĝia tunelo ankoraŭ aspektas sana. Observu la eksvalidiĝon de la kontakto anstataŭ la staton de la tunelo.
Kiam la softfono sidas malantaŭ la tunelo, la kontakt-kaplinio povas porti privatan adreson. PBX, kiu plusendas ĝin al alia finpunkto, kreas dialogon celantan reton, kiun la vokato ne povas atingi. Agordi rewrite_contact=yes ĉe la PJSIP-finpunkto igas la PBX anstataŭigi la fontan adreson, kiun ĝi observis, kaj tio ofte estas la diferenco inter sonorado kaj tempolimo.
Kion la INVITE proponas kaj kiu povas uzi ĝin
INVITE kun SDP-korpo proponas, kie la vokanto volas ricevi mediojn: adreso, pordo kaj kodeka listo. La vokato respondas per sia propra adreso kaj pordo, kaj poste ĉiu flanko sendas RTP al tio, kion la alia proponis. Se la vokanto proponis adreson 192.168.x.x, kiu ekzistas nur en lia hejma reto, la vokato havas nenie por sendi sonon, kiom ajn pura estis la signalado. Maskado reskribas IP-kapliniojn dum pakoj forlasas enkursigilon, sed ĝi neniam reskribas la tekston ene de SDP-korpo.
Tiu breĉo klarigas la klasikan unudirektan vokon: signalado funkcias ĉar ambaŭ finpunktoj atingas la PBX, kaj sono malsukcesas ĉar al unu finpunkto oni diris sendi al adreso, kiu ekzistas nur malantaŭ alia 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 |
Kiu portas la sonon estas elekto de agordo
Signalado kaj medioj estas apartaj roloj. Prokurilo povas resti sur la signala vojo dum tuta voko kaj neniam tuŝi eĉ unu RTP-pakon. Ĉu la PBX iĝas media relajso dependas de la agordo, ne de la ĉeesto de tunelo.
Ĉe rekta medio la finpunktoj mem interŝanĝas RTP, kio bone funkcias en unu LAN kaj malbone, kiam unu flanko sidas malantaŭ mallarĝa pord-aro.
Agordi direct_media=no pelas la PBX en la mediovojo, por ke ambaŭ kruroj finiĝu ĉe adreso, kiun ĝi kontrolas, interŝanĝante bendolarĝon kaj CPU por antaŭvidebla adresado. Kiam ĝi relajsas, la PBX ankoraŭ devas anonci atingeblan adreson. Ĉe plurretea gastiganto, external_media_address kaj external_signaling_address en pjsip.conf decidas, kio aperas en SDP kaj en Via-kaplinioj. Se vi lasos ilin neagorditaj, la PBX povas proponi sian LAN-adreson al vokanto, kies sola vojo estas la malproksima flanko de la tunelo.
Spuru ĉiun direkton antaŭ ol tuŝi agordojn
Komencu per la inga tabelo sur la PBX dum voko estas aktiva: ss -uanp | grep -E '5060|10000' montras, ĉu RTP-pordoj estas ligitaj kaj kiun lokan adreson ili uzas. Se nenio estas ligita en la media aro, la relajso ne partoprenas kaj la finpunktoj parolas rekte. Poste kaptu ĉe la softfona flanko per tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap. Elirantaj pakoj sen enirantaj pakoj mallarĝigas la problemon al la revena vojo aŭ al la adreso, kiun oni diris al la malproksima fino uzi, kaj malplena kapto signifas, ke medioj neniam atingis la tunelan interfacon. Signala kapto per sngrep respondas la alian duonon montrante la SDP-konektan linion tiel, kiel ĝi estis sendita.
Komparu la adreson en tiu konekta linio kun la adreso, al kiu la malproksima fino efektive povas enkursigi. Tiu unu komparo solvas la plej multajn unudirektajn sonraportojn pli rapide ol iu ajn agorda revizio.
Ĉifrado haltas ĉe la rando de la tunelo
SIP per TLS protektas la signalan salton, por kiu ĝi estis agordita, SRTP protektas mediojn, kiam ambaŭ finoj interkonsentas pri ĝi, kaj la tunelo protektas trafikon inter siaj propraj finpunktoj. Neniu el tiuj donas la aliajn. Voko ĉifrita ene de la tunelo povas forlasi la enirejon en klara teksto direkte al la PBX, kaj tio estas dizajna decido, ne difekto.
Antaŭ ol fermi la bileton, konfirmu tri aferojn laŭ ordo: la registrado estas freŝa, la SDP portas adreson, kiun la malproksima fino povas atingi, kaj pakoj fluas ambaŭdirekte sur la mediaj pordoj. Se iu el tiuj estas malvera, la tunelo ne estas kie loĝas la problemo. Riparu la vojon, kiu malsukcesis, kaj poste ripetu la saman kapton por konfirmi la ŝanĝon. Konservi la kaptojn antaŭ kaj post igas la sekvan unudirektan raporton kviminuta kontrolo anstataŭ tuta posttagmezo.