Miksi SIP-puhelu rekisteröityy VPN:n yli mutta ei lähetä ääntä
Rekisteröinti ja ääni kulkevat eri reittejä. Seuraa yhtä puhelua tunnelin läpi ja näe, mitä osoitteita PBX voi käyttää ja mihin RTP todella pysähtyy.
Onnistunut rekisteröinti ei kerro äänestä juuri mitään. Softphone voi pitää kelvollisen sidonnan toimiston PBX:ään tunteja ja välittää silti hiljaisuutta. Tunneli kuljettaa vain ne paketit, jotka joku tarkoituksella siihen lähettää, ja puhelu käyttää kolmea erillistä reittiä: sidonta, dialogin pystytys ja RTP-virta. Kun erotat ne, vika osuu yhdelle reitille sanan VPN sijaan.
Kuvittele kannettava tietokone kodin Wi-Fi-verkossa soittamassa toimiston sisänumeroon hyväksytyn tunnelin kautta. PBX todentaa käyttäjän, hyväksyy REGISTERin ja sisänumero näkyy saatavilla, mutta puhelu yhdistyy täyteen hiljaisuuteen yhteen suuntaan.
Rekisteröinti sitoo kontaktin, ei mediapolkua
REGISTER-pyyntö pyytää rekisteröijää tallentamaan vastaavuuden osoitteen ja yhden tai useamman kontaktin URI:n välillä. Tämä vastaavuus vastaa kapeaan kysymykseen siitä, mihin uusi dialogi pitäisi juuri nyt lähettää. Se ei kerro mitään siitä, mihin media kuuluu, eikä hyväksytty rekisteröinti todista, että myöhempi INVITE kuljettaa saavutettavaa mediaosoitetta. Rekisteröinnit myös vanhenevat ajastimella, joten puhelin, joka lopettaa päivittämisen, menettää saapuvat puhelut, kun taas sen tunneli näyttää yhä terveeltä. Tarkkaile kontaktin vanhenemista tunnelin tilan sijaan.
Kun softphone on tunnelin takana, kontaktin otsake voi sisältää yksityisen osoitteen. PBX, joka välittää sen toiselle päätepisteelle, luo dialogin verkkoon, johon kutsuttu ei pääse. rewrite_contact=yes-asetus PJSIP-päätepisteessä saa PBX:n korvaamaan havaitsemansa lähdeosoitteen, ja se on usein ero soiton ja aikakatkaisun välillä.
Mitä INVITE tarjoaa ja kuka voi käyttää sitä
SDP-rungon sisältävä INVITE ehdottaa, missä soittaja haluaa vastaanottaa mediaa: osoite, portti ja koodekkiluettelo. Kutsuttu vastaa omalla osoitteellaan ja portillaan, ja sitten kumpikin osapuoli lähettää RTP:tä sille, mitä toinen ehdotti. Jos soittaja ehdotti 192.168.x.x-osoitetta, joka on olemassa vain hänen kotiverkossaan, kutsutulla ei ole paikkaa lähettää ääntä, niin puhdas signalointi oli kuin oli. Maskeeraus kirjoittaa uudelleen IP-otsakkeet pakettien poistuessa reitittimestä, mutta se ei koskaan kirjoita uudelleen SDP-rungon sisällä olevaa tekstiä.
Tämä aukko selittää klassisen yksisuuntaisen puhelun: signalointi toimii, koska molemmat päätepisteet pääsevät PBX:ään, ja ääni epäonnistuu, koska yhdelle päätepisteelle sanottiin, että lähetä osoitteeseen, joka on olemassa vain toisen NATin takana.
| 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 |
Kuka äänen kuljettaa, on kokoonpanovalinta
Signalointi ja media ovat erillisiä rooleja. Välityspalvelin voi pysyä signalointireitillä koko puhelun ajan eikä koskaan kosketa yhtäkään RTP-pakettia. Se, tuleeko PBX:stä mediatehä, riippuu kokoonpanosta, ei tunnelin olemassaolosta.
Suorassa mediassa päätepisteet vaihtavat RTP:n itse, mikä toimii hyvin yhdessä lähiverkossa ja huonosti, kun toinen puoli on kapean porttialueen takana.
direct_media=no-asetus työntää PBX:n mediapolulle, jotta molemmat haarat päättyvät sen hallitsemaan osoitteeseen, vaihtamalla kaistanleveyden ja suorittimen ennustettavaan osoitteistukseen. Välittäessään PBX:n on silti mainostettava saavutettavaa osoitetta. Usean verkkoliitännän isännässä external_media_address ja external_signaling_address tiedostossa pjsip.conf päättävät, mitä SDP:ssä ja Via-otsakkeissa näkyy. Jos jätät ne asettamatta, PBX voi tarjota lähiverkko-osoitettaan soittajalle, jonka ainoa reitti on tunnelin kaukainen puoli.
Seuraa kumpaakin suuntaa ennen asetuksiin koskemista
Aloita PBX:n pistoketaulukosta, kun puhelu on käynnissä: ss -uanp | grep -E '5060|10000' näyttää, ovatko RTP-portit sidottuja ja mitä paikallista osoitetta ne käyttävät. Jos media-alueella ei ole mitään sidottuna, tehostin ei ole mukana ja päätepisteet puhuvat suoraan. Kaappaa sitten softphonen puolella komennolla tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap. Lähtevät paketit ilman saapuvia paketteja rajaavat ongelman paluureitille tai osoitteeseen, joka kaukaiselle puolelle kerrottiin käytettäväksi, ja tyhjä kaappaus tarkoittaa, että media ei koskaan saavuttanut tunnelin liitäntää. Signaloinnin kaappaus komennolla sngrep vastaa toiseen puoliskoon näyttämällä SDP-yhteysrivin sellaisena kuin se lähetettiin.
Vertaa kyseisen yhteysrivin osoitetta osoitteeseen, johon kaukainen puoli todella pystyy reitittämään. Tämä yksi vertailu ratkaisee useimmat yksisuuntaisen äänen raportit nopeammin kuin mikään kokoonpanon tarkastus.
Salaus pysähtyy tunnelin reunaan
SIP TLS:n yli suojaa sen signalointihypyn, jota varten se määritettiin, SRTP suojaa mediaa, kun molemmat päät neuvottelevat siitä, ja tunneli suojaa liikennettä omien päätepisteidensä välillä. Mikään näistä ei anna toisia. Tunnelin sisällä salattu puhelu voi poistua yhdyskäytävästä selkokielisenä kohti PBX:ää, ja se on suunnittelupäätös, ei vika.
Ennen tiketin sulkemista vahvista kolme asiaa järjestyksessä: rekisteröinti on tuore, SDP sisältää osoitteen, johon kaukainen puoli pääsee, ja paketit virtaavat molempiin suuntiin mediaporteilla. Jos jokin näistä on väärin, tunnelissa ei ole ongelmaa. Korjaa reitti, joka epäonnistui, ja suorita sitten sama kaappaus uudelleen vahvistaaksesi muutoksen. Ennen ja jälkeen otettujen kaappausten säilyttäminen tekee seuraavasta yksisuuntaisen äänen raportista viiden minuutin tarkistuksen kokonaisen iltapäivän sijaan.