Společnost Espressif Systems oznámila, že rodinu SoC ESP32 brzy rozšíří o ESP32-H4 s IEEE 802.15.4 a Bluetooth 5.4 (LE) s podporou protokolů Thread 1.3, Zigbee 3.0 a Bluetooth Mesh 1.1.
Kevin Bentley zveřejnil na GitHubu zdrojové kódy počítačové hry Descent 3 z roku 1999: "Někdo se nedávno zeptal, zda budou zveřejněny zdrojové kódy Descent 3. Oslovil jsem svého bývalého šéfa (Matt Toschlog) z Outrage Entertainment a ten mi to povolil. Budu pracovat na tom, aby se to znovu rozběhlo a hledám spolusprávce." [Hacker News]
Byla vydána verze 0.81 telnet a ssh klienta PuTTY. Opravena je kritická bezpečnostní chyba CVE-2024-31497 obsažena ve verzích 0.68 až 0.80. Používáte-li klíč ECDSA NIST P521 a použili jste jej v PuTTY nebo Pageantu, považujte jej za kompromitovaný.
Hra MineClone2 postavena nad voxelovým herním enginem Minetest byla přejmenována na VoxeLibre.
Společnosti Avast Software s.r.o. byla pravomocně uložena pokuta ve výši 351 milionů Kč. Tu uložil Úřad pro ochranu osobních údajů za neoprávněné zpracování osobních údajů uživatelů jejího antivirového programu Avast a jeho rozšíření internetových prohlížečů (Browser Extensions), k čemuž docházelo prokazatelně po část roku 2019.
… více »Bylo vydáno do češtiny přeložené číslo 714 týdeníku WeeklyOSM přinášející zprávy ze světa OpenStreetMap.
V sobotu 20. dubna lze navštívit Maker Faire Jihlava, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Knihovna pro potlačení šumu RNNoise byla vydána ve verzi 0.2. Kvalitu potlačení lze vyzkoušet na webovém demu.
FRRouting (FRR) (Wikipedie), tj. softwarová sada pro směrování síťové komunikace, fork Quagga, byl vydán ve verzi 10.0.
Julian Andres Klode vydal APT (Advanced Packaging Tool) ve verzích 2.9.0 a 2.9.1. Jedná se o vývojové verze nové větve APT 3.0. Vylepšuje se uživatelské rozhraní. Přidány byly barvičky. Aktuální náhledy a vývoj lze sledovat na Mastodonu.
Potrebuji poradit jakym zpusobem propojit 2 sip proxy jedouci na Opensips? Pokud se zaregistruji na jeden sip proxy (oba klienty), tak se v pohode dovolam, ale jakmile mam na obou sip proxy pripojene klienty, tak se nemuzu dovolat. Vazne komunikace mezi obema sip proxy. Mohl by mi nekdo poradit jak to zprovoznit, abych se mohl dovolat z kazdeho KZ na druhe KZ pres oba sip proxy?
moznosti je strasne vela. ale napada ma kazdemu SERu nastavit samostatnu domenu a volat medzi nimi cez SIP URI. Napr: sip:telefon1@sip1.domena.cz a sip:telefon2@sip2.domena.cz
alebo mozes prepisovat hlavicky a na tvrdo to posielat na druhy SER, to chce ale uz troska skriptovania...
A mohl by jste mi poradit jak na to (nejsem jeste moc zbehly). Ja jsem premyslel o VPN mezi obema sip servery.
tak rozbehnut to uz je relativne narocna zalezitost (a Vam to uz bezi, takze zbehly ste 
). ak poviete nieco blizsie o tom, popisete konfiguraciu, tak nie je problem poradit..
Potreboval bych poradit jak nastavit ty sip proxy, aby sla komunikace i pres Internet. Na sip proxy mam nainstalovany OpenSIPS(debian), ale nakonfigurovany je mam pouze defaulte. Pokud se prihlasim oba klienty na jeden sip proxy, tak se v pohode dovolam, ale pokud na kazdy sip proxy registuji jednoho klienta, tak se nemuzu dovolat. Komunikace nejspis vazne mezi komunikaci mezi temi sip proxy. Tak pokud nevite jak se nastavuji na vzajemnou komunikaci.
no tak z principu fungovania SIPu by malo stacit z jedneho telefonu zavolat URI sip:username@192.168.1.1 kde za @ je IP adresa druheho proxy servera a pred zavinacom je ucet volaneho klienta. ak to funguje cez net s firewallmi, budu tam problemy ako tok rtp, tok signalizacie (bez record-routy), myslim ze toto opensips neriesi defaultne. nebudete mat lepsie pouzit nejaky Asterisk? tam su naroky na skonfigurovanie podstatne nizsie (za cenu flexibility)
se omlouvam za ot, ale bmp je nevhodna volba. na malobarevnou grafiku je idealni PNG (jednak je dokumentovany cely a druhak ma skvelou kompresi) (otevrit treba v gimpu, ulozit jako png a jsi na 11kB , pokud snizis pocet barev na 8, tak na 4kB ... lepsi jak stehovat 0.5MB po siti...)
opensips neznam... u asterisku byly veci jako canreinvite - tj. jestli se klienti maji snazit propojit na sebe naprimo nebo ne. A nasledne - pokud volate konkretniho klienta - jak ho "urcite" - vi ta proxy co po ni chcete? (v pripade asterisku je to otazka dialplanu a pristupujete k tomu jako k telefonnim cislum - rikate mu, se kterym ma co udelat.)
takze naozaj nestaci z telefonu 2.100 volat SIP URI v tvare sip:klient@192.168.2.102? kde klient je username toho SIP telefonu na 2.103? toto by malo fungovat a ak nie, mate divne nakonfigurovany OpenSIPS...
Porad se mi to nedari propojit. Myslim ze mam problem s NAT, mam to rozjete na dvou compech(virtualbox). Popis: na debianech mam spusteny opensips(ke konfiguraci mam poze zakazany TLS, nic vic jsme nenastavoval). Chtel jsem to napred rozchodit bez jakehokoliv zabezpeceni. Jakym zpuseobem by jsem to teda mel nakonfigurovat.
ano nat je vzdy probem a v procese rozbehavania odporucam sa mu vyhnut uplne (skusat to na strojoch ktore sa realne vidia). rovnako kazdy pokus sniffovat napr. cez tcpdump a nasedne analyzovat (presiel vygenerovany INVITE z telefonu1 cez opensips1 na opensisp2? dostal sa az do druheho telefonu? atd...) wiresharkom.
opensips je velmi silny software, urobite s nim takmer vsetko, ale za cenu celkom zloziteho studia (poznat aspon zaklady SIPu je podmienka).
btw, mozete postnut Vas opensips.conf?
Pozn. Provoz mezi sip proxy bych chtel provozovat pres internet. Tak podle meho bych mezi nimi mel vytvorit VPN, nevite jak na to? Na obou sip proxy mam Debian/opensips.
OpenVPN?
riesit to cez VPN mi pride trosku tazkotonazne riesenie, ale ak trvate na bezpecnosti...
ak nie, podstatne lepsie sa mi zda nasadenie TLS na SIP signalizaciu (sifrovanie), a RTP pustit volne do netu (pripadne pouzit srtp/zrtp). to, ze je signalizacia sifrovana podstatne stazuje ucastnikovi najst konkretny rtp stream, ktory chce odpocuvat...
z principu fungovania protokolu SIP a RTP prebieha cez opensips len SIP signalizacia, RTP ide medzi terminalmi na priamo, co ale v prostredi internetu a NAT nefunguje. preto budete musiet nasadit nejaku formu rtpproxy/mediaproxy (co tiez nie je uplne trivialna zalezitost).
skratka, bez studia to nepojde, ale mozete skusit asterisk 
Nečetl jsem celou diskusi jen jsem se všim těch IP... to mi příjde, že máte v obou sítích asi stejné rozsahy.. Což by do jisté míry mohl být problém- Kdyby jste měl v té sítí nalevo IP co napravo a navíc to nebyl telefon, tak si nezavolate...
Pak bych možná zvážil využití Registrar serveru.. Proxy stateless jen přepojuje sama víc neumí.. takže ty vaše proxy jsou stateful?
Prave ze vsechny 4 zarizeni mam ve stejne siti(KZ1-192.168.2.101,opensips1-192.168.2.102,opensips2-192.168.2.103,KZ2-192.168.2.104), nastaveni opensips mam v defaultnim nastaveni(pouze vyply TLS) bez pouziti databaze MySQL. Vsechny zarizeni mam pripojene do routeru. Nevite kde se treba nastavuje aby sip proxy byla v rezimu statefull nebo stateless,redirect,registrar....Diky
Jak jsem jiz psal, OpenSIPS se nenastavuje. Pisete pro nej "program", jak ma zachazet s jednotlivymi zpravami.
Nejjednoduseji si to muzete predstavit tak, ze OpenSIPS je sada knihoven a Vy znich pomoci opensips.conf udelate finalni program. Je to obdobne, jako byste napr. pomoci PHP a xajaxu vytvarel vlastni Ajax server. Akorat je to trosicku slozitejsi...
Hezky den!
Omlouvám se OpenSIPs neznám ani OpenSER.. Zkuste, jestli nebude jednodušší použít třeba asterisk a ty dvě proxy propojit protokolem IAX.. na to je na netu řada návodů. Dosáhnete fakticky toho samého, ale jinou cestou.
1. Nejsem si jist, ze pouziti dvou proxy serveru je rozumne - proc Vam nestaci jeden? Dva maji vyznam snad jen pri rozkladu zateze a neverim tomu, ze byste byl snadno schopen SER/Kamailio/OpenSIPS tak snadno "pretizit"
2. "Propojit" proxy nijak nejde Jde vytvorit takovou konfiguraci, aby si proxy mezi sebou prehazovaly urcite typy SIP zprav (napr. INVITE). Docilt toho muzete milionem ruznych zpusobu, napr. pomoci nastaveni R-RURI ci zmenou DST-URI a statefull forwardovanim (t_relay), ci proste bezstavove poslanim zpravy na adresu druhe proxy pomoci "forward".
3. Vsechno zalezi na tom, jak presne maji danne proxy fungovat a tudiz jak mate zkonstruovan routovaci skript. Obavam se, ze obecna rada neexistuje.
Zkratka a dobre bych Vam,. pane kolego Petre, doporucil poradne zkontrolovat Vas vlastni routovaci skript (ten ukazkovy pribalovany k SER-like serverum je opravdu UKAZKOVY, nikoliv urceny k pouzivani), zkontroloval skutecnou cestu SIP zprav pomoci sitoveho snifferu (treba ngrep) a pokud Vam neco nebude jasne, zkuste se zeptat konkretne.
BTW: Naprosto zasadni je kompletni zanalost SIP protokolu. Pokud si svymi znalostmi nejste jist, zkuste sepodivat na http://tech-invite.com kde je hezke "graficke" intro do SIPu.
Hezky den!
Jak jsem jiz uvedl na zacatku, tak jsem zelenac. Mojl by jste mi blize priblizit jak a kde se nastavuje R-RURI,DST-URI a statefull forsardovanim. Vsechny jsou to pojmy zname,ale nemam s nimi prakticke zkusenosti. Tak pokud mi muzete problizi blizsi konfiguraci v opensips. A jeste jsem se chtel pozeptat na ten routovaci skript.Nezlobte se za pro Vas jiste samozrejme veci.
Vse se nastavuje (spise bych rekl ridi) v routovacim skriptu - ve Vasi reinkarnaci SERu to bude opensips.conf. To je vlastne program napsany v takovem jednoduchem programovacim jazyku, ktery ridi modifikace SIP zpráv, jejich smerovani a v nekterych pripadech tez odpovedi na ne. Tvorba routovaciho skriptu neni vubec trivialni zalezitost a pochopit jak presne to funguje je otazkou spise tydnu, nez dnu. Takze bych Vam spise doporucil prostudovat si nejake materialy o SIPu obecne a potom nejake intro do SERu/Kamailia/OpenSIPSu. Vsechny tri komunity sdruzene okolo zminenych projektu cato poradaji uzitecne vyukove seminare jejichz navsteva se nepochybne vyplati.
Aby to nevypadalo, pane kolego Petre, ze jsem vas jenom takto odbyl, zkusim odpovedet i na Vase otazky, ale nejsem si jist, zda Vam to bude uzitecne:
1. Terminologie: R-URI - SIP adresa pro niz je zprava urcena, DST - SIP adresa kam je zprava poslana
2. Priklady: Chcete-li SIP zpravy urcene pro 12345 poslat na druhe proxy na adrese 1.2.3.4:5070 muzete to udelat takto
a) if ($rU == "12345") { rewritehostport("1.2.3.4:5070"); t_relay(); };
b) if ($ru =~ "sip:12345@.*") { forward("1.2.3.4:5070"); };
a samozrejme jeste temer libovolnou kombinaci predchozich prikladu + milionem dalsich zpusobu. To zalezi jen a pouze na tom, jake zpravy, kdy a kam chcete smerovat.
Hezky den!
Jeste jsem se chtel zeptat, jak by vypadala "prakticka" implementace SRV zaznamů. Jestli bych musel vytvorit DNS server? Nebo se to da nejak nakonfigurovat pomoci opensips.cfg nebo nejakym takovym zpusobem.
"SRV" znamena "DNS SRV", takze ano, jedna se druh DNS zaznamu, tudiz je budete spravovat pomoci (jakehokoliv) DNS serveru.
Nevim, ceho presne chcete docilit, ale skoro bych Vam doporucil si zatim zivot pomoci DNS SRV nekomplikovat. Nejdrive si napiste nejaky funkcni opensips.conf a az ho budete mit vyzkouseny, vyladeny a 100% spravny, zacnete s laborovanim s DNS SRV. Ladit oboje najednou je "silna kava" pro kohokoliv
Hezky den!
Podle me je prave tam kamen urazu. Prave ze ty oba sip proxy o sobe nevi. Tak sem vycetl, ze se to da vyridit bud pomoci SRV nebo statickym mapovanim.
Ne. DNS SRV zaznamy nemaji (nesmeji mit) s ridicim skriptem pranic spolecneho. Ty jsou uzitecne pro jednoduchou prioritizaci prenosoveho protokolu (UDP, TCP) pripadne (spolu s NATPTR) pro rozklad zateze atp.
Ale v kazdem pripade se to tyka pristup koncovych zarizeni k SIP serveru a nikoliv serveru jako takoveho.
Zkratka a dobre - pro zacatek zapomente, ze DNS vubec existuje, nakreslete si presny a kompletni obrazek kdy, kam a proc maji jake typy SIP zprav chodit, jake zmeny na ne maji byt aplikovany a pak se pokuste vytvorit odpovidajici program (opensips.conf), ktery to zaridi. Nasledne pomoci ngrepu zaznamenejte veskerou komunikaci, najdete odchylky od Vaseho puvodniho planu a trasujte Vas program (opensips.conf), abyste zjistil, kde delate neco jinak, nez jste puvodne planoval. Jinak se k cili nikdy nedoberete
Hezky den!
Mozna ze se zeptam dost blbe, ale nevite jak se prida do staticke smerovani adresy sip proxy? Chtel bych aby signalizace prochazela pres oba sip proxy. Pry se to da udelat pomoci statickeho mapovani. Muzete mi aspon naznacit praktickou implementaci do opensips.conf. Proste chci pridat zaznam u obou proxy. Vysledkem by melo byt neco takoveho :
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.2.1 ............
Via: SIP/2.0/UDP 10.0.0.2 ............
Via: SIP/2.0/UDP 10.0.1.1 ............
1--d87543-;rport=62572
Record-Route: <sip:10.0.2.1;lr=on>
Record-Route: <sip:10.0.0.1;lr>
.....................................
Proste potrebuji nejak zapsat servery pres ktery ma jit signalizace, at mi nevynechava jeden server.
Aby boli proxy v signalizacnej ceste pocas celeho dialogu, musite v prvotnom INVITE ktory zaklada dialog pridat Record-Routu. Ta sa v dalsej tranzakcii (napr. ACK, BYE) preklopi v user agentovi na Routu a tym mate zabezpecene ze proxy ostane v signalizacnej ceste az do konca dialogu.
priklad praktickej implementacie, dufam ze som sa moc v syntaxi nesekol
route {
#ak request obsahuje Route hlavicku, odroutujeme na tu adresu + odstranime nasu IP (no je to o dost komplikovaniejsie, lepsie precitat RFC3261 :-))
if (loose_route()) {
t_relay();
}
#matchneme INVITE ktory zacina dialog
if ( (method==INVITE) && (!has_totag()) {
record_route(); #pridame Record-Route hlavicku
}
}
Takze kdybych chtel pridat dve adresy napr.sip proxy 192.168.2.2 a sip proxy 192.168.2.1, tak bych to udelal jak? Muzete byt prosim konkretnejsi co a kam dopsat? Neni mi to uplne jasne. Dekuji
no tak ako som napisal, kazda proxy by mala pridat len sama seba (cez funkciu record_route()). tj. urobit record_route() na kazdej proxine..
ale aj tak si myslim, ze toho co sa snazite dosiahnut od zaciatku toho vlakna, ak mate opensips s defaultnym konfigom co je dodavany ako demo-priklad (btw. preco ste ho sem davno neposlali?) tak to musi fungovat bez akehokolvek zasahu do konfiguracie...
Mam to udelane takto: klient1-server1 (1 subnet),server1-server2 (2 subnet), server2-klient2 (3 subnet). Takze mam 3 site. Klient1 je zeregistrovany na sip proxy (server1). Klient2 je zaregistrovany u druhe sip proxy (server2). Servery mezi sebou routuji. Kdyz volam z prvniho klienta1 druheho klienta2, tak signalizace jde od prvniho klienta pres sip proxy(server1) a jakoby vynecha dalsi sip proxy (server2) a jde primo na klienta2,volani se uskutecni, ale vynechava se vzdy ten druhy server (u toho volaneho klienta). Tak jsem myslel, ze by bylo nutne staticky zadat record-route toho druheho sip proxy (server2),aby signalizace sla i pres tento sip proxy(server2). V priloze mam dannou konfiguraci. Muzete mi rici, kde mam co nastavit a zapsat?
a aku URI tocite z klienta1? (komplet SIP uri)
Tocim URI serveru 2, tedy pokud klient 2 ma user name 1111, vytacim z klienta1 SIP: 1111@10.0.2.1, kde 10.0.2.1 je adresa, u ktereho je kliant2 registrovany.
tak v tom pripade sa mi to zda divne, pretoze record_route() ten skript urobi, takze by obe proxiny mali ostat v singnalizacnej ceste (keby nie, tak uz ACK aj BYE ide na priamo mimo oboch proxin).
- obsahuje INVITE ktory pride na klienta2 hlavicku/y Record-Route s dvoma zaznamami oboch proxin?
ak ano, tak to musi preliezt vzdy cez obe (a v konfiguracii nevidim preco by sa to malo spravat inak)
mozete este skusit urobit kompletne sipove logy na oboch strojoch kde je openser a pastnut to sem (pcap logy tcpdump/ngrep/wireshark)
inak Vas musim pochvalit ze ste vo svojom snazeni vytrvali a vidiet ze Vas skill prudko stupol oproti prvemu komentaru v diskusii
Tady je zachycene spojeni z wiresharku, od obou sip proxy, volal jsem z klienta1 na klienta2. Je asi teda zrejme, ze klient1 vynechava sveho sip proxy, ale to nechapu proc.
dalsi
Jak by jste tedy upravil dany opensips.cfg, podle vas? Tak aby sla signalizace pres vsechny prvky.
ale neposielajte screenshoty (ktore sa navyse nedaju ani prelustit) ale rovno ulozte vo wiresharku ten log do suboru a poslite ho sem, nie screenshoty...
Tady jsou
no ale podla toho logu to funguje ako potrebujete. SIP signalizacia ide medzi proxy a nie na priamo. Od INV po BYE...
to ze RTP ide medzi UA na priamo je normalna vlastnosti a ma to tak fungovat. (ale ste nenapisali ze s tymto mate problem, ale problem so SIPom, co nie je RTP)...
v pripade ze chcete aby Vam slo aj audio medzi opensipsami a nie na priamo, musite pouzit nejake mediaproxy (rtpproxy/mediaproxy) ktore spojite s opensipsom...
napr: http://www.rtpproxy.org/
To vim, ale podle me by to melo vypadat dle prilohy.
Jeste bych se chtel na neco zeptat. Abych pro zabezpeceni komunikace mezi serverama mohl vyuzivat TLS, tak je asi nutne na oba servery nainstalovat OpenSSL, ze? Nemate nejaky navod na zprovozneni? Diky
Jeste mam maly problem. Stahl jsem si opensips-1.4.4-TLS_src.tar.gz, tedy s podporou TLS. Ale nedari se mi ho zkompilovat dle obrazu sveho. Nainstaluje se to bez podpory TLS a ani zde neni zahrnut modul db_mysql. I kdyz podpora TLS by mela byt zahrnuta. Nevite kde by mohla byt chyba?
Pri kompilaci to vypise ze zacatku toto:
bison -d -b cfg cfg.y
cfg.y: conflicts: 1 shift/reduce
flex cfg.lex
Mel bych jeste jeden dotaz o pomoc. Zkompiloval jsem si opensips s podporou TLS. Spustim proces generovani certifikatu pro CA viz. priloha., tp probehne v pohode. Pak chci vygenerovat samotny certifikat, ale to uz neprobehne ,viz.priloha. Nevite, kde by mohla byt chyba?
Dovolim si upozornit, ze record_route() je vhodne pouzit pro cokoliv krome REGISTER a ne jenom pro INVITE.
A taktez je lepsi "zavolat" record_route() pred loose_route(), protoze dobre implementovanemu SIP stacku tyto nadbytecne hlavicky vadit nebudou (neb je bude ignorovat) a spatne SIP stacky (napr. Asterisk) bez toho smeruji spatne...
Hezky den!
Obavam se, ze mam naprosto odlisny nazor
1. Existuji i jine "metody" u nichz byste pravdepodobne RR hlavicky mohl ocenit - napr. MESSAGE...
2. Pokud nebudou in-dialog zpravy obsahovat RR hlavicky, tak Vam spousta klientu prestane fungovat (napr. vsechny Asterisky < cca 1.4.21). Ano, muzete argumentovat tim, ze to je chyba klienta a "at si to opravi". A samozrejme budete mit pravdu. Na druhou stranu - pouhym "record_routovanim" vsech in-dialog zprav temto problemum elegantne a uplne predejdete. Cili si muzete vybrat (jako ostatne v mnoha dalsich castech SIPu), bud se budete snazit dodrzovat RFC vylucne nebo Vam bude smerovani packetu fungovat. Ja hlasuji pro druhou moznost.
BTW: Pred par dny byla o tomto tematu cila diskuse v mailinglistu Kamailia ci OpenSIPSu...
Hezky den!
len tlacit vyrobcu nech si to opravi, lebo uz je v SIPe taky balast a taky bordel, ze SIP na to uz bohuzial doplaca. Asterisk nastastie uz nepouzivam, ale podla toho co hovorite, to musi byt fakt mega-bug ak sa to takto sprava az sa mi to zda neuveritelne :)
je to mailing list kamalia alebo opensipsu? su to 2 projekty, maju este stale spolocny mailing list?
1.
Ja vim, jak si martani v IETF mysleli, ze ma SIP fungovat (odhledneme ted od toho, ze spousta "sipovskych" RFC si navzajem odporuje). Skutecnost je vsak zcela jina. A tak ma prakticky kazdy operator na vyber - bud stavet SIP servery jako "RFC kompatibilni" nebo jako funkcni. Oboje najednou IMO nejde. Alespon o zadne takove instalaci nevim
2.
Bordel to nedela, protoze to vsichni vedi a pocitaji s tim
Venkoncem - Asterisk v tom neni sam - podivejte se, jake SIP hnusy produkuje Sonus, Cirpack, CISCO...
1+2
Pro in-dialog MESSAGE plati totez, co pro jakoukoliv jinou SIP metodu - nema-li RR hlavicky, tak ji spousta klientu smeruje spatne.
3.
Jak jsem psal vyse - nepamatuji si, v jake konferenci to bylo (odebiram obe) - google jiste poradi
Hezky den!
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
10.2.2009 22:50
