Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Na rootu vyšel zajímavý článek, který by si měl přečíst každý, kdo používá Skype - 10 důvodů proč nepoužívat Skype. Po přečtení článku se zamyslíte, jestli je dobré vůbec Skype používat.
Tiskni
Sdílej:
V?ivot? nesly?eli o SIPu a IAXu?Sly?eli, ale v?dy ve spojitosti s n?jakou komer?ní voip slu?bou. Takovou drobnost, ?e jde volat p?ímo z klienta na klienta se ?lov?k nikde nedozví, pokud nechce louskat RFC?ka.
Bohu?el doty?ní asi netu?í, ?e krom? SIPu je tui onen IAX, který s NATem ?ádné problémy nemá (a u? ho dokonce za?ínají i podporovat nov?j?íhardwarové VoIP telefony). Stejn? jednoduché jako pou?ívat Skype je pou?ívat IAX klienta (nap?. Kiax) a k p?ipojovat se t?eba p?es freeworlddialup.com. Dokonce kvalita hovor? je co tak mohu ze svých zku?eností posoudit o dost lep?í ne? p?es Skype.Pro? se o tomhle doprkna nikde nepí?e? Pro? vychází furt v?ude ?lánky o Skype (pochvalné nebo odsuzující) a nikdy ?ádný o alternativách? To je pak celkem jasné, ?e to vypadá, ?e ty alternativy neexistují. BTW, IAX vypadá super, kiax jakbysmet (akorát ten freeworlddialup.com se mi n?jak nezdá), díky za upozorn?ní.
Takovou drobnost, ?e jde volat p?ímo z klienta na klienta se ?lov?k nikde nedozví, pokud nechce louskat RFC?ka.uff ... a to jak? je to ji? del?í dobu, co jsem RFC3261 ?etl celé a nechce se mi do toho znovu, mohl bych poprosit o nakopnutí, kde hledat, jak SIPovat bez serveru?
Bohu?el doty?ní asi netu?í, ?e krom? SIPu je tu i onen IAX, který s NATem ?ádné problémy nemáIAX? a to je co? a jak to ten NAT ?e?í? - samoz?ejm? jsem si zagoogloval, a o IAXu jsem na?el jen reklamní kecy, ale vysv?tlení ?ádné (kde to má n?jaké RFC?ko?) u? jenom v?ta "Instead of using Real-time Protocol (RTP), IAX uses User Datagram Protocol (UDP ) over a single Internet port (Port 4569) to transmit and receive signaling and media." je teda perla ... za prvé, RTP a UDP jsou protokoly zcela jiných vrstev, tak?e nelze ?íct "instead of", an?to RTP taky pou?ívá UDP, tak?e UDP místo UDP? - pon?kud blbost ... ale budi?, p?ekousn?me básnickou licenci, dejme tomu, ?e tím bylo my?leno jak to konkrétn? po tom UDP b?há, tak?e za druhé - je-li stabilní port, jak se ?e?í více klient?? resp. NAT p?elo?í odchozí port klienta na náhodný port NATujícího routeru, jak se chce druhá strana spolehnout na konkrétní ?íslo?
Pro? vychází furt v?ude ?lánky o Skype (pochvalné nebo odsuzující)i negativní reklama je reklama ... a jinak obecná lidská tendence vybrat si to nejnevhodn?j?í ?e?ení ...
Naprosto jednodu?e - ve?kerá komunikace (jak kontrolní/signální, tak i samotná data) probíhá narozdíl od SIPu p?es jeden jediný UDP kanál na jediném portu (standardn? 4569).hm, to jsem si ji? p?e?etl, o tom jednom portu - ale stále nechápu, jak to zabrání problém?m s NATem ...
Velmi doporu?uji p?e?íst si ?lánek IAX versus SIP.ten jsem ?etl jediný bod, ve kterám se mluví o NATu, je ?íslo 4 a ten to nijak nevysv?tluje - jo pardon, mluví o adminovi firewallu, já se ov?em ptám, jak si IAX poradí s NATem bez zásahu admina (kdy? mám mo?nost konfigurovat firewall, procpu bez problém? nejen SIP, ale i tém?? kterýkoliv jiný protokol ...)?
Jinak vubec spoustu informací o IAXu najdete ZDE.ani z této stránky nevede odkaz na ?ádné vysv?tlení problému NATu
Opravdu nechápu ty va?e kecy o "chvástání" a reklamních materiálech.sundejte si r??ové brýle a p?e?t?te si to je?t? jednou - a p?e?t?te si také n?co o SIPu, kdy? jsme u toho, jinak byste nemohl psát (opisovat) v?ci jako:
Navíc IAX má oproti SIPu i podstatn? men?í re?ii, datový tok je obvykle cca o 2,5kB/s men?í ne? u SIPu (p?i pou?ití stejného kodeku).mluvit o n?jakém kodeku u SIPu je v tomto kontextu blbost, SIP slou?í p?esn? k tomu, jak se jmenuje, data jsou pak (v typickém p?ípad?) p?ená?ena nezávisle na SIPu nap?. prost?ednictvím RTP (ano, pomocí SIPu se m??e dohodnout kodek, ale tím to kon?í) ... to je jako ?íkat, ?e jabka jsou lep?í ne? hru?ky, proto?e z jablek se d?lá ?trúdl - ano, a co kdy? zrovna ?tr?dl nechci, umo?ní mi IAX t?eba hrát koresponden?n? ?achy? nebo z jiného soudku: IAX supports PKI-style authentication and trunking. When trunking with IAX2, only the used bandwidth is allocated at all times. Other TDMoIP protocols used for trunking always allocate a certain amount of bandwidth to keep all channels open. hm, oni implementaci trunkingu u IAX presentují jako ohromnou výhodu - a nenese tato výhoda s sebou i tu nevýhodu, ?e v p?ípad?, kdy pásmo není reservované, nemusí se poda?it uskute?nit dal?í hovor? - IMO je to ?ulnul, tak?e ?íci výhodu a zaml?et nevýhodu v tomto p?ípad? snad nelze chápat jinak, ne? jako reklamu, pokud nebudeme tak naivní a neslu?ní k autorovi, ?ebychom si mysleli, ?e je tak blbej a o té nevýhod? neví
To co do?tete v ?láncích co sem vám dával jsou prostá fakta,nejsou - tedy p?inejmen?ím nijak jste nedolo?il, ?e IAX s NATem problémy nemá
stejn? jako je faktem ?e SIP má s NATem v n?kterých p?ípadech nep?ekonatelné problémy,nevím, pro? musíte neustále opakovat, jak je SIP ?patný, kdy? je ?e? o otázce, jakým zp?sobem je ?e?en NAT v IAX - nikde snad netvrdím, ?e SIP s NATem roblémy nemá ...
kde?to IAX ?ádné problémy nemá.tak?e si to shr?me: - jestli jsem to správn? pochopil, IAX komunikuje mezi dv?ma klienty bez proxy serveru, tzn. navazuje se mezi nimi p?ímé spojení - p?edstavme si klienty A a B, p?i?em? B je za NATem a má adresu v privátní síti - klient A chce navázat spojení a) klient A není schopen poslat Internetem cokoliv do privátní sít? (RFC 1918) - konec b) klient A nezná adresu B v privátní síti, ale zná ve?ejnou adresu routeru s NATem, za kterým je B schovaný, po?le tedy paket na adresu routeru na portu 4569 1) router p?edtím pou?il port 4569 jako odchozí pro n?jaké spojení po?íta?e C (C je ve stejné síti jako B) a o?ekává na n?m odpov??, aby ji mohl forwardovat na po?íta? C, tak?e paket od A bu? po?le C, který ho zahodí, nebo ho zahodí rovnou, proto?e p?ichází z jiné adresy, ne? kam p?edtím posílal po?adavek od C - v obou p?ípadech konec 2) router z portu 4569 nic neposílal, tudí? je zav?ený, paket se zahodí (ICMP port unreachable) - konec jak to IAX ?e?í?
Tim ze se v problematice asi bezne nepohybujete ...jo, to RFC 3261 jsem četl jenom jednou
davaji do datove casti paketu IP adresy komunikujicich stran. To je nesvar, ktery cini NATovani velmi obtiznym.proč? - proxy prostě přidá do topmost via parametry received a rport, takže při návratu to jde na adresu, ze které to skutečně přišlo, nikoliv co o sobě tvrdí odesílající strana, a cestu mezi proxy a ue nezajímá, co je obsahem paketu ...
Krome toho ma IAX furu dalsich dobrych vlastnosti, ale zadnou metodu jak projit NATem na privatni adresu, ktera nenavazala zadne spojeni smerem ven, nema.děkuji, to jsem chtěl slyšet takže z hlediska NATu je na tom stejně jako SIP, jen to zřejmě řeší o něco méně krkolomně ... což je ovšem poněkud jiný závěr, než původní tvrzení, že IAX narozdíl od SIPu problémy s NATem nemá ...
… jak SIP tak H323 jsou hnusne protokoly typu FTP, davaji do datove casti paketu IP adresy komunikujicich stran. To je nesvar, ktery cini NATovani velmi obtiznym.s/datove casti paketu/kontrolniho spojeni/
IAX prichazi s beznym resenim (ale z hlediska VoIP revolucnim) kdy v paketech IP adresy nejsou a spoleha na bezne NATovaci mechanizmy. Proto vsichni rikaji, ze je IAX skvely pro NAT, protoze se da natovat jako kazdy inteligentni protokol jak SNATem tak DNATem a netrva na dodrzeni cisel portu ani jinych obtiznych veci.Ano, souhlasim, ze v pripade zanatovaneho inetu je lepsi netahat do aplikacni vrstvy adresy nizsich vrstev. Protoze pak namisto aplikacnich proxy serveru staci obycejny portforwading. Nicmene, nelze zpochybnit, ze oddeleni datoveho toku od kontrolniho prinasi i jiste vyhody. Predevsim samotna data nemusi (ale mohou) jit pres proxy, cimz snizuji zatez linek (kratsi spojeni) a zatez serveru (nemusi tolik dat forwardovat). Tento prvek je podstatny u protokolu prenasijici obrovska mnozstvi dat (proto se objevil uz u FTP), ale kdyz budete mit SIP proxy pro stovky/tisice uzivatelu, pak i ty kilobity audiostreamu nabydou. A nakonec je treba prijmout, ze SIP je pouze signalizacni protokol, o konkretni streamovani se nestara. V tomto smeru je IAX pomerne specializovany a tim padem i omezeny. A nakonec pro netfilter existuje modul conntrackujici SIP a RTP relace.
<sip:identifikator_druhe_strany@IP_adresa_druhe_strany>
a pokud vam nestoji v ceste firewall, tak se klienti spoji i bez jakehokoliv serveru.
Vselijake proxy, registrare, STUN servery apod. nejsou nutne, pokud nejse za NATem nebo firewallem a znate adresu volaneho.
Co se tyce IAXu, tak to je pristupovy protokol pro H.323 gatewaye, ktery by mel byt jednodussi nez klasicky pritupovy protokol. Problem H.323 je, ze je strasne slozity na implementaci. Jako klienta muzete zkusit GnomeMeeting.
Zasadni rozdil oproti Skypu je ten, ze se Skypem si instalujete v jedne binarce jak klienta, tak proxy server. Takze pak to "samo" funguje, kdezto u SIP nebo H.323 si musite ten server sam najit (pokud jste za NATem) a pripojit se na nej.
Ja na firme Skype obdivuji, ze dokazala nasadit pomerne tezkotonazni reseni, ktere se umi vyrovnat se zaNAToavnimi sitemi, aniz by firma Skype musela provozovat vlastni proxy servery (krome tech par meta supernodu). O neco podobneho se v komercni sfere jeste nikdo nepokusil. Na extremni problem extremni reseni.
Kde?to IAX (verze 2) je ?e?en tak, ?e ... a vyhýbá se problém?m které nap?. SIP má (problémy s NATem, atp.).ho?ím touhou dozv?d?t se, jak se ten NAT ?e?í, ale odkazy m? zatím p?íli? neuspokojily, prosím vysv?tlete mi to u? n?kdo ...
Pro prakticke cviceni si nainstalujte nejake dva SIPove klienty ...to m? pobavilo
Pak tomu jednomu dejte zavolat druheho ucastnika pomoci URL <sip:identifikator_druhe_strany@IP_adresa_druhe_strany>
a pokud vam nestoji v ceste firewall, tak se klienti spoji i bez jakehokoliv serveru.
pravda, neuv?domil jsem si, ?e klient sám sebe zná i bez toho, aby se registroval ... asi u? jsem fakt deformovanej A kdy? mi po?lete mail, jak se dovíte moji adresu? Kdy? mi budete chtít poslat n?co p?es Jabber, jak se dovíte moji jabber adresu. Ani jedno SMTP ani Jabber ne?e?í, ale p?esto mi spousta lidí pí?e maily a kecá se mnou po jabberu. Jak to sakra d?lají?Pak tomu jednomu dejte zavolat druheho ucastnika pomoci URLpravda, neuv?domil jsem si, ?e klient sám sebe zná i bez toho, aby se registroval ... asi u? jsem fakt deformovanej<sip:identifikator_druhe_strany@IP_adresa_druhe_strany>
a pokud vam nestoji v ceste firewall, tak se klienti spoji i bez jakehokoliv serveru.
host -t any 1.0.4.7.9.0.0.0.9.9.2.8.8.e164.org 1.0.4.7.9.0.0.0.9.9.2.8.8.e164.org has NAPTR record 100 10 "u" "E2U+IAX2" "!^\\+88299000974(.*)$!iax2:guest@sip.rudna.net/88299000974\\1!" .A dozvite se, ze se mate spojit s nasi ustrednou na adrese sip.rudna.net protokolem IAX jako guest a ze mame 100 cisel od +8829900097400 do +8829900097499 a ze tedy mate po spojeni vytocit jeste 01, abyste se dostali na spravnou pobocku. To umoznuje zavolat z telefonu, ktery ma na klavesnici jen cislicka, coz je u telefonu jednak dost caste a jednak dost podstatne. Mimochodem, kdyby to nekdo chtel fakt zkusit, tak ja nemam 01, ale 70. Ale ted jdu do sveta