Wêrom't in SIP-oprop oer in VPN registrearret mar gjin lûd stjoert
Registraasje en lûd folgje ferskate paden. Folgje ien oprop troch de tunnel om te sjen hokker adressen de PBX brûke kin en wêr't RTP eins stopt.
In slagge registraasje fertelt jo hast neat oer lûd. In softphone kin oerenlang in jildige bining mei de kantoar-PBX hâlde en dochs stilte leverje. De tunnel draacht allinnich de pakketten dy't immen der bewust yn stjoert, en in oprop brûkt trije aparte paden: bining, dialoochopbou en de RTP-stream. Sadree't jo dy skiede, falt de flater op ien paad ynstee fan op it wurd VPN.
Stel jo in laptop foar op thús-Wi-Fi dy't in kantoarextinsje kiest fia in goedkarde tunnel. De PBX ferifiearret de brûker, akseptearret de REGISTER, en de extinsje ferskynt as beskikber, mar dochs ferbynt de oprop mei deade loft yn ien rjochting.
Registraasje bindt in kontakt, net in mediapaad
In REGISTER-fersyk freget de registrator om in koppeling op te slaan tusken in adres-fan-rekord en ien of mear kontakt-URI's. Dy koppeling beantwurdet in smelle fraach oer wêr't in nije dialooch no stjoerd wurde moat. It seit neat oer wêr't media heart, en in akseptearre registraasje bewissiget net dat in lettere INVITE in berikber media-adres draacht. Registraasjes ferrinne ek op in timer, dus in telefoan dy't ophâldt mei fernijen ferliest ynkommende oproppen wylst syn tunnel noch sûn liket. Sjoch nei it ferrinnen fan it kontakt ynstee fan de tunnelstatus.
As de softphone efter de tunnel sit, kin de kontaktkop in privee adres drage. In PBX dy't dy trochstjoert nei in oar einpunt makket in dialooch rjochte op in netwurk dat de oproppen partij net berikke kin. It ynstellen fan rewrite_contact=yes op it PJSIP-einpunt lit de PBX it waarnommen boarne-adres ferfange, en dat is faak it ferskil tusken in beljen en in timeout.
Wat de INVITE biedt en wa't it brûke kin
In INVITE mei in SDP-lichem stelt foar wêr't de skilker media ûntfange wol: in adres, in poarte en in koadektalist. De oproppen partij antwurdet mei eigen adres en poarte, en dêrnei stjoert elk fan beide kanten RTP nei wat de oare foarstelde. As de skilker in adres 192.168.x.x foarstelde dat allinnich yn syn thúsnetwurk bestiet, hat de oproppen partij gjin plak om lûd nei te stjoeren, hoe skjin de sinjalearring ek wie. Maskering skriuwt IP-koppen oer as pakketten in router ferlitte, mar it skriuwt nea de tekst yn in SDP-lichem oer.
Dat gat ferklearret de klassike ienrjochting-oprop: sinjalearring wurket omdat beide einpunten de PBX berikke, en lûd mislearret omdat ien einpunt sein waard te stjoeren nei in adres dat allinnich efter in oare NAT bestiet.
| 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 |
Wa't it lûd draacht is in konfiguraasjebeslissing
Sinjalearring en media binne aparte rollen. In proxy kin in hiele oprop op it sinjalearringspaad bliuwe en nea ien RTP-pakket oanreitsje. Oft de PBX in mediarelee wurdt, hinget ôf fan de konfiguraasje, net fan it bestean fan in tunnel.
Mei direkte media wikselje de einpunten sels RTP út, wat goed wurket op ien LAN en min as ien kant efter in smel poarteberik sit.
It ynstellen fan direct_media=no twingt de PBX yn it mediapaad sadat beide skonken einigje op in adres dat hy kontrolearret, en ruilet bânbreedte en prosessor foar foarsisbere adressaasje. As er releelet, moat de PBX noch hieltyd in berikber adres oankundigje. Op in host mei meardere netwurken beslisse external_media_address en external_signaling_address yn pjsip.conf wat yn SDP en yn Via-koppen ferskynt. Lit se net ynsteld en de PBX kin syn LAN-adres oanbiede oan in skilker waans iennichste rûte de fiere kant fan de tunnel is.
Folgje elke rjochting foardat jo ynstellingen oanreitsje
Begjin mei de sokketabel op de PBX wylst in oprop aktyf is: ss -uanp | grep -E '5060|10000' lit sjen oft RTP-poarten bûn binne en hokker lokaal adres se brûke. As neat yn it mediaberik bûn is, is de relee net ynskakele en prate de einpunten direkt. Meitsje dan opname oan de softphone-kant mei tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap. Utgeande pakketten sûnder yngeande pakketten ferneauje it probleem nei it werompaad of nei it adres dat de fiere kant sein waard te brûken, en in lege opname betsjut dat media de tunnelinterface hielendal net berikt hat. In sinjalearringopname mei sngrep beantwurdet de oare helte troch de SDP-ferbiningsline te sjen sa't dy stjoerd is.
Fergelykje it adres yn dy ferbiningsline mei it adres dêr't de fiere kant echt nei rûte kin. Dy iene fergeliking lost de measte ienrjochting-lûdmeldingen rapper op as hokker konfiguraasje-oersjoch dan ek.
Fersifering stopt by de râne fan de tunnel
SIP oer TLS beskermet de sinjalearringssprong dêr't it foar ynsteld is, SRTP beskermet media as beide kanten it úthannelje, en de tunnel beskermet ferkear tusken syn eigen einpunten. Net ien fan dy jout de oaren. In oprop dy't yn de tunnel fersifere is, kin de gateway yn platte tekst rjochting de PBX ferlitte, en dat is in ûntwerpbeslissing, gjin defekt.
Foardat jo it ticket slute, befêstigje trije dingen yn folchoarder: de registraasje is farsk, de SDP draacht in adres dat de fiere kant berikke kin, en pakketten streame beide kanten op oer de mediapoarten. As ien fan dy falsk is, is de tunnel net wêr't it probleem wennet. Reparearje it paad dat mislearre, en rin dan deselde opname opnij om de feroaring te befêstigjen. It bewarjen fan 'e opnamen foar en nei makket it folgjende ienrjochting-rapport in fiifminutenkontrôle ynstee fan in hiele middei.