Laikinai nepasiekiama

Pastarosiomis dienomis aš nukreipinėju savo flynumber DID į du skirtingus SIP tiekėjus ir vis iš jūsų gaunu „Temporarily Unavailable“ pranešimus. Telefonas visai neskamba, nors iš paties telefono aš galiu skambinti į išorę. Žinau, kad tai nėra NAT problema, nes aš darau port forwarding visiems SIP prievadams į patį įrenginį, be to, kartais viskas veikia visiškai gerai. Tačiau kartais būna visiška „tamsa“, kai telefonas neskamba ir aš gaunu šiuos „Temporarily Unavailable“ pranešimus.

Antra, toks elgesys pasireiškia su dviem skirtingais SIP tiekėjais, todėl pradedu atidžiau žiūrėti į flynumber ir bandau suprasti, kas čia gali vykti.

Ar galėtumėte tiksliai paaiškinti, ką reiškia „Temporarily Unavailable“ ir kokiomis aplinkybėmis atsiranda ši klaida?

Žinau, kad įrenginys gali pasiekti SIP serverius ir atvirkščiai, nes naudoju ne tik NAT port forwarding, bet ir STUN serverį.

Prašau, padėkite man.

Sveiki

Apgailestaujame tai girdėdami…

Patikrinome jūsų numerį ir jis veikia gerai, panašu, kad problema yra nukreipimo paskirties vietoje

Tai nebūtų niekaip susiję su mumis, kadangi jūsų dabartinis FlyNumber nukreipimo nustatymas yra tik įeinantiems skambučiams

Ar yra būdas, kaip galėtume pabandyti be įjungto STUN?

Paprastai tai reikštų, kad SIP URI, į kurį mes siunčiame skambučius, dėl vienokių ar kitokių priežasčių nepriima ryšio. Galbūt jūsų VoIP paslaugų teikėjas reikalauja tam tikros autentifikacijos, kad būtų galima siųsti skambučius ten?

Gali būti, kad jūs neįtraukėte mūsų IP adresų į savo sistemą.

Štai pavyzdinis Asterisk ir mūsų IP adresai, kurie padės jums teisingai tai nustatyti

Norėdami matyti naujausius skambučius skambučių istorijoje, nustatykite „Iki“ datą viena diena į ateitį (žinoma klaida, kurią taisome)

Jei problema išliks, prašome parašyti asmeninę žinutę arba atidaryti užklausą ir pridėti bet kokius jūsų sistemos pateikiamus klaidų žurnalus

Štai šiek tiek bendros informacijos apie NAT, kuri gali padėti jūsų situacijoje …

Network Address Translation (NAT) yra įprasta praktika tinkluose ir ji prastai dera su VoIP. Šios problemos sprendimui reikia suprasti NAT, VoIP ir jūsų VoIP konfigūraciją. Toliau daugiausia dėmesio skiriama SIP protokolui VoIP ryšiui naudojant Asterisk, tačiau problemos ir sprendimai taikomi daugumai kitų situacijų.

NAT gali sukelti problemų keliose vietose. Jei viena iš PBX stočių yra už NAT šliuzo, kita PBX stotis negalės su ja susisiekti be papildomos tinklo konfigūracijos. Jei vienas ar daugiau telefonų yra už NAT šliuzo, kitas telefonas bandys siųsti garsą į nemaršrutuojamą adresą. Tai lemia nepavykusius skambučius arba dingstantį garsą.

Alternatyva re-invite (pakartotiniam pakvietimui) yra leisti PBX retransliuoti balso paketus tarp dviejų galinių taškų.

SIP klientas yra už NAT šliuzo ir jungiasi prie serverio internete

Klientas sukuria transliacijos (translation) įrašą SIP srautui, kai pirmą kartą registruojasi. Kol tarp dviejų mazgų vyksta dažnas ryšys, pavyzdžiui, vienas paketas per minutę, kanalas išliks atviras. Vienintelė reikalinga konfigūracija – nurodyti, kad klientas visuose SDP paketuose naudotų savo išorinį adresą. Klientuose, kurie tai palaiko, įjunkite STUN (Simple Traversal of UDP through NAT), kad klientas galėtų dinamiškai nustatyti išorinį adresą, arba įveskite jį rankiniu būdu. Asterisk šiuo metu nepalaiko STUN, todėl visa NAT konfigūracija turi būti atliekama rankiniu būdu. Šios komandos faile /etc/asterisk/sip.conf tinkamai sukonfigūruoja NAT:

[general]

localnet=192.168.0.0/255.255.0.0 // arba jūsų potinklis

externip=x.x.x.x // naudokite savo adresą

[YOURREMOTEPEER] // jūsų peer pavadinimas

nat=yes

qualify=yes // priverstiniai keepalive paketai

Su šia konfigūracija Asterisk naudoja externip nurodytą adresą visiems skambučiams į peers, kuriems nustatyta nat=yes. qualify=yes pridėjimas priverčia Asterisk dažnai tikrinti ryšį, kad NAT transliacijos nebūtų pašalintos iš užkardos. Su šiomis dviem komandomis tarp Asterisk ir peer visada bus ryšio kanalas, o Asterisk naudos išorinį adresą, kai siųs SDP pranešimus.

Keli SIP telefonai ir Asterisk serveris už NAT šliuzo

Skambučiai tarp telefonų veiks gerai, nes NAT nereikalingas. Tačiau skambučiams tarp jūsų ir kitų sistemų internete kils problemų. Jei neregistruositės nuotolinėje pusėje kaip klientas (kaip padaryta ankstesniame pavyzdyje), negalėsite gauti SIP pranešimų, taigi negalėsite priimti skambučių. Antra, skambučio nustatymo metu naudojama adreso informacija rodys į vidinį telefono adresą, ir iškils anksčiau minėtos vienpusio garso problemos.

Lengviausias sprendimas – visiškai išvengti NAT. Jei turite viešą IP adresą savo skambučių serveriui, naudokite jį. Jei jūsų Asterisk serveris prijungtas ir prie interneto, ir prie vidinio tinklo, SIP prievadas yra pasiekiamas tiek iš vidaus, tiek iš išorės, ir vienintelė problema – užtikrinti tinkamą RTP srautą. PBX serverio nereikia konfigūruoti maršrutizavimui tarp sąsajų ar masquerading funkcijai; jam tereikia sujungti (bridge) įeinančius ir išeinančius balso skambučius.

Kaip minėjau anksčiau, PBX gali arba likti balso kelyje, arba pasitraukti iš jo. Pastaruoju atveju PBX informuoja abu galinius taškus vieną apie kitą, po to galiniai taškai kalbasi tiesiogiai. Tačiau Asterisk gali turėti skambučio nustatymą su abiem galiniais taškais ir retransliuoti RTP paketus kiekvieno galinio taško vardu. Vidinis mazgas kalbėtų su vidiniu adresu, o išorinis mazgas – su išoriniu adresu. Vienintelė reikalinga konfigūracija, kad tai pasiektumėte faile sip.conf, yra išjungti re-invites:

[general]

canreinvite=no // priverstinis retransliavimas

Ši konfigūracija veikia gerai, nes Asterisk serveris gali laisvai kalbėtis su internetu, kad siųstų ir priimtų skambučius. Jis taip pat gali kalbėtis su vidiniais telefonais ir, naudodamas paprastą sujungimą (bridging), visiškai ignoruoti NAT.

Paaiškėja, kad toks retransliavimo elgesys taip pat yra būtinas, kai Asterisk serveris turi tik privatų adresą. RTP prievadai taip pat turės būti peradresuoti užkardoje. RTP pasirenka atsitiktinius prievadų numerius pagal sukonfigūruotas ribas. Prieš konfigūruojant prievadus, jų diapazonas turėtų būti apribotas. Užkardos taisykles konfigūruoti daug lengviau, jei prievadų diapazonas žinomas iš anksto.

RTP naudojamų prievadų diapazonas apibrėžiamas faile rtp.conf. Ši konfigūracija apribos Asterisk pasirenkamus RTP prievadus nuo 10000 iki 20000:

[general]

rtpstart=10000 // pirmasis naudojamas prievadas

rtpend=20000 // paskutinis naudojamas prievadas, suapvalinamas į viršų, jei nelyginis

Asterisk tinkamam darbui reikės kelių RTP prievadų. Iš tikrųjų naudojami tik lyginiai prievadai, o re-invites išjungimas lemia, kad kiekvienam skambučiui sukuriami du ryšiai. Šie prievadai ir SIP prievadas tuomet turi būti peradresuoti užkardoje. iptables sintaksė yra:

iptables -t nat -A PREROUTING -i eth0 -p udp \

-m udp --dport 10000:10100 -j DNAT \

–to-destination 192.168.1.10

iptables -t nat -A PREROUTING -i eth0 -p udp \

-m udp --dport 5060 -j DNAT \

–to-destination 192.168.1.10

Pakeiskite eth0 į išorinę jūsų užkardos sąsają ir 192.168.1.10 į jūsų Asterisk serverio adresą. Šios taisyklės nurodo Linux branduoliui išversti bet kurių UDP paketų, patenkančių per išorinę sąsają nurodytame diapazone, paskirties adresą. Tai turi vykti PREROUTING etape, o ne POSTROUTING etape, nes verčiamas paskirties adresas. Šiuo momentu bet kuris SIP ar RTP paketas iš interneto bus persiųstas į vidinį Asterisk serverį apdorojimui.

Kai nuotolinė stotis skambina į Asterisk, SIP paketas bus persiųstas į vidų dėl iptables taisyklių. Asterisk liks medijos sraute dėl canreinvite=no komandos ir naudos užkardos išorinį adresą bet kuriuose SDP paketuose dėl NAT komandų. Galiausiai, medijos srautas bus persiųstas į Asterisk serverį dėl iptables RTP peradresavimo ir rtp.conf apibrėžtų prievadų diapazonų kombinacijos.

Iki šiol konfigūracija daugiausia buvo orientuota į Asterisk veikimą už NAT šliuzo, su keliais papildomais niuansais, kad telefonai retransliuotų srautą per Asterisk. Žinoma, yra ir bendresnių sprendimų.

Jei galite išvengti NAT iš pat pradžių, tai yra jūsų interesuose, nes taip išvengsite visų iki šiol aptartų problemų.

Asterisk šliuzui galima taikyti labai griežtą užkardos politiką – tereikia leisti UDP 5060 SIP srautui ir bet kokį prievadų diapazoną, apibrėžtą rtp.conf. Esant tokiai konfigūracijai, Asterisk gali susisiekti ir su vidiniais telefonais, ir su likusiu internetu.

Jei SIP nėra būtinas reikalavimas ir jūs naudojate Asterisk, apsvarstykite galimybę naudoti IAX protokolą. IAX tuneliuoja ir valdymo, ir balso srautą per vieną UDP sesiją, kurią galima lengvai peradresuoti, filtruoti ar versti. Šis metodas yra apribotas statiniu tunelių rinkiniu, kas yra pakankama, jei jungiate kelias PBX stotis per internetą arba jungiatės prie tolimojo ryšio tiekėjo.

Kartais aukščiau išvardyti sprendimai jums gali būti neprieinami. Tokiu atveju gali būti tikslinga pereiti prie pilnai funkcionalaus SIP proxy ir naudoti Asterisk tik balso programoms, tokioms kaip balso paštas. SIP Express Router (SER) yra galingas SIP serveris, kuris gerai tvarkosi su NAT ir yra naudojamas kelių didelės apimties paslaugų, įskaitant Free World Dialup. SER užduotis – tik nustatyti skambučius tarp galinių taškų, todėl jis turi pasikliauti kitomis programomis, tokiomis kaip specializuoti medijos proxy, kad prireikus apdorotų RTP srautus.

Žingsnis toliau už SIP proxy yra Session Border Controller (SBC), kuris yra tarsi VoIP užkarda. SBC gali įsikišti tiek į signalizacijos, tiek į RTP kelius, kad pridėtų papildomų funkcijų, tokių kaip signalizacijos protokolo ar kodeko vertimas, tuo pačiu vykdydamas saugumo politiką. Tai beveik išimtinai komerciniai produktai.

gerai, šį savaitgalį toliau testuosiu ir atnaujinsiu temą, kai tik turėsiu daugiau informacijos. Bandžiau ir su STUN, ir su NAT Keep Alive, bet esu atlikęs prievadų persiuntimą (port forwarding) įeinančiam SIP 5060 ir RTP srautui, todėl STUN ir NAT šiame atvejyje iš tikrųjų neturėtų būti būtini.

Antra, aš persiunčiu flynumber į CWU ir, sprendžiant iš įvairių forumų, atrodo, kad toks derinys yra tinkamas, nes yra ir daugiau žmonių, kurie taip naudoja. Galiausiai, išbandžiau kitą DID tiekėją (kitą nei DIDWW perpardavėjas), kad įsitikinčiau, jog problema nėra ta, kaip DIDWW serveriai pasiekia CWU.

Aš ir toliau atnaujinsiu šią temą.
Ačiū už atsakymą.

Teisingai, jei galime laikyti STUN išjungtą testavimo metu, tai galėtų padėti

Kol tavo tiekėjas leidžia SIP srautą iš išorinių tiekėjų, viskas turėtų būti gerai. Galbūt norėsi jų paklausti, kokie yra reikalavimai, kad skambučiai būtų siunčiami į jų serverius

Jei ko nors prireiks, mes esame čia, kad padėtume