Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
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.
V poslední době se neustále v souvislosti s VoIP mluví o Skype. Avšak Skype je aplikace s uzavřeným kódem (closed-source) využívající proprietární protokol. Proč je používání takovéto služby (alespoň z mého pohledu) špatné, jste se mohli dočíst např. v článku 10 důvodů proč nepoužívat Skype, který vyšel na serveru Root.cz. Viz také zápis v blogu Co je tak špatného na Skype?
Nejstarším rozšířeným otevřeným VoIP protokolem je H.323 (standardizován ITU-T). Jde o protokol s velmi blízkou návazností na technologie používané na ISDN linkách. Jedná se o binární protokol a k přenosu audio dat jsou používány RTP kanály. Z nejrůznějších důvodů se od něj však ustupuje (ukázalo se, že pro současný internet to není zrovna nejvhodněji navržený protokol), naprostá většina VoIP operátorů místo něj již používá novější protokol SIP.
SIP (Session Initiation Protocol) je novějším otevřeným protokolem, který byl standardizován IETF. Na rozdíl od H.323 (který měl kořeny v telekomunikačním průmyslu) leží jeho kořeny v internetové komunitě. Jde o decentralizovaný peer-to-peer protokol. Oproti H.323 se jedná o textový protokol, podobný např. známému HTTP. Samotná audio data jsou však přenášena stejně jako v případě H.323 přes samostatné RTP kanály. SIP měl být původně jednodušší než H.323, ale postupem času se stal taktéž velmi komplexním protokolem. Jde o dobře promyšlený protokol, ve kterém je budoucnost, nicméně i on má svůj závažný problém - provoz za NATem.
Na "probourání" NATu je možno použít protokol STUN (Simple Traversal of UDP over NATs). Ten funguje zjednodušeně řečeno tak, že klient (uvězněný za NATem) se spojí se STUN serverem a STUN server mu následně sdělí veřejnou IP adresu stroje, kde probíhá NAT, a číslo UDP portu, který byl NATem otevřen. Tato technika ovšem funguje pouze pro full cone, restricted cone a port restricted cone NAT. Pro klasický a nejrozšířenější symetrický NAT (který provádí např. iptables) je tato technika nepoužitelná. V takovém případě je pak nutno provádět SIP spojení přes vzdálený proxy server, což má samozřejmě spoustu nevýhod - mohou se projevit velké latence a provoz takového SIP proxy serveru navíc může být dosti náročný. Nutno ještě podotknout, že H.323 má s NATem prakticky zcela stejné problémy, jako SIP.
Je tu ovšem i jiný otevřený protokol, který problémy s NATem nemá. Tím protokolem je IAX (Inter-Asterisk eXchange). Jedná se o nejnovější ze všech jmenovaných protokolů, který původně sloužil pro komunikaci mezi opensource PBX servery Asterisk. Byl navržen od začátku tak, aby netrpěl problémy s NATem a měl pokud možno co nejmenší režii. IAX se inspiroval protokoly SIP, MGCP a RTP, ale snaží se vyhnout všem jejich problémům. Na rozdíl od SIPu se nejedná o textový protokol, ale o binární protokol (což lze považovat za krok zpět, ale je to z hlediska koncepce tohoto protokolu nutné). Veškerá komunikace (jak signalizace, tak audio data) probíhá přes jeden jediný UDP kanál (výchozí port je 4569) a v tom právě tkví důvod, proč tento protokol nemá problémy s NATem. Nejedná se o žádné revoluční řešení, je to zcela standardní řešení a NAT není nijak zázračně obcházen (pokud jsou obě dvě strany za NATem, přímé spojení mezi nimi fungovat nebude), ale oproti SIPu a H.323 je to stále velká výhoda (i když z určitého úhlu pohledu může být spojení signalizace a datového kanálu do jednoho chápáno i jako nevýhoda).
Další výhodou je zmiňovaná menší režie - při použití IAXu bývá datový tok až cca o 2,5kB/s nižší než při použití SIP (respektive RTP). To činí při použití zvukových kodeků s nízkým bitrate 20 - 30% úsporu. Ještě mnohem významněji se to ale projevuje díky schopnosti IAXu vytvářet trunky, kdy při více souběžných spojeních mezi stejnými koncovými body (např. při spojení mezi dvěma VoIP PBX ústřednami) umí sloučit data všech spojení do jednoho paketu, a výrazně tak šetří přenosovou kapacitu (díky eliminaci hlaviček). Údajně je tak např. možné při využití kodeku G.729 oproti SIPu zdvojnásobit (někde se píše až ztrojnásobit) počet možných hovorů na jeden megabit pásma.
Shrnuto a podtrženo - H.323 se v současnosti již pomalu stává mrtvým protokolem, nepoužívá ho už prakticky žádný VoIP provider. SIP se stal jednoznačně nejrozšířenějším VoIP protokolem a do budoucna se bude stále více a více rozšiřovat. Podporuje ho prakticky každý hardwarový VoIP telefon a i většina softwarových klientů. IAX je méně rozšířený, ale VoIP provideři ho pomalu, ale jistě, začínají čím dál tím více využívat a podporují ho i některé novější hardwarové VoIP telefony. Nelze však říci, že SIP je oproti IAXu špatný protokol. Pouze naráží na problém současného rozšíření NATů. To vyřeší buď příchod IPv6, nebo vhodný connection tracking (již nyní existují patche na iptables, umožňující conntrackovat SIP).
VoIP klientů (softwarových telefonů) podporujících SIP existuje mnoho. Zde je výčet těch, které jsem objevil:
Osobně používám KPhone, který je jednoduchý na ovládání, ale přitom obsahuje spoustu užitečných funkcí. I přes ono "K" v názvu se jedná o čistou Qt aplikaci bez závislostí na KDE. Občas se mi ovšem jevil trochu nestabilní. Pokud chcete velice jednoduchý klient založený na GTK, pak je pro vás asi nejlepší volbou Linphone. Jako dobří klienti se jeví i SFLphone, OpenWengo a PhoneGaim (přičemž poslední dva jsou svým zaměřením velmi vhodné i pro BFU a integrují i funkce IM klienta). Ostatní SIP klienty v seznamu jsem nezkoušel a netuším, na jaké jsou úrovni (nejedná se ale o moc známé projekty).
Seznam IAX klientů je již kratší:
Zde musím vyzvednout Kiax. Jedná se o výborného klienta, který disponuje i některými velice pokročilými funkcemi. Svým rozhraním trochu připomíná linuxovou verzi Skype. Stejně jako v případě KPhone je zde ono "K" v názvu zavádějící (též se jedná o čistou Qt aplikaci). iaxComm je také slušným klientem, tentokrát napsaným ve wxWindows toolkitu (tudíž pod linuxem využívá GTK). Ostatní klienti jsou méně známí a poslední jmenovaný (QtIAX) je spíše už starším projektem, o kterém nevím, zda je ještě vůbec použitelný (rozhodně již není vyvíjený).
Nebylo by také vhodné zapomenout na GnomeMeeting - kvalitní VoIP klient určený pro protokol H.323. Ten má totiž v některé z brzkých verzí již obsahovat podporu pro protokol SIP. Také SFLphone (výše zmiňovaný SIP klient) má v brzké budoucnosti začít podporovat další protokoly - v tomto případě IAX. Pro známý IM klient Gaim je v rámci Google Summer of Code taktéž chystána podpora pro SIP (kód je již napsán a byl commitnut do CVS).
Pokud chcete VoIP plnohodnotně používat, potřebujete být zaregistrováni u některého z VoIP operátorů. Pro jednoduchou hlasovou komunikaci z jedné IP adresy na druhou IP adresu VoIP operátora nepotřebujete (můžete např. přímo volat z jednoho SIP klienta na druhý SIP klient, aniž byste byli připojeni k jakémukoliv SIP serveru), ovšem VoIP při takovém využití ztrácí spoustu svých výhod. Můžete také provozovat svůj vlastní H.323/SIP/IAX server (nabízí se např. už jednou zmiňovaný opensource PBX Asterisk nebo jednodušší SIP Express Router). Mnohem lepší řešení pro běžného uživatele ovšem je zaregistrovat se u některého z free VoIP providerů. Velkých free providerů je několik:
Všichni z nich podporují SIP, ale pouze jeden jediný (Free World Dialup) podporuje IAX. Nutno dodat, že Free World Dialup je jedním z nejstarších VoIP operátorů vůbec a je i tak trochu průkopníkem VoIP. Mám s ním velmi dobré zkušenosti, a tak ho také všem doporučuji. Jen je nutné nenechat se odradit jeho webovými stránkami, které jsou velmi nepřehledné. Naštěstí se na nich vyskytuje spásný odkaz SITEMAP. Pokud se chcete přímo zaregistrovat, můžete tak učinit na stránce EndUser Registration. Ještě je také nutné pamatovat na to, že pokud chcete používat kromě SIPu i IAX, musíte si IAX po registraci aktivovat (viz FAQ o IAX).
Velmi důležitým faktem je, že mezi mnoha VoIP operátory probíhá peering (ze sítě jednoho VoIP operátora se zdarma můžete dovolat do sítě druhého VoIP operátora a naopak). Free World Dialup má velmi slušný peeringový seznam a peerují s ním i někteří čeští komerční VoIP operátoři (např. VoIPEX).
Od všech ostatních výše jmenovaných free VoIP operátorů se liší operátor Like2Fone. Podporuje sice pouze protokol SIP, ale nabízí jednu úžasnou věc navíc - ENUM. Uživatelům nepřiděluje telefonní čísla z virtuálních neveřejných rozsahů, ale mapuje reálná veřejná telefonní čísla (např. telefonní číslo vaší pevné linky) na konkrétní internetové identity. Můžete si tak v internetu volat pomocí stejných čísel, jako v reálném světě. Pokud se vám na vaše číslo pak snaží dovolat někdo, kdo využívá služeb operátora, který standard ENUM podporuje, vyzkouší se nejdříve vaše internetové SIP číslo a až poté (pokud jste na něm nedostupný) klasické číslo vedoucí na pevnou linku či mobilní síť. Výhodu to má jasnou - pokud vám volá někdo přes VoIP operátora, hovor putuje pouze přes internet a je tedy zcela zdarma.
Standard ENUM je podporovaný ITU (International Telecommunication Union) a využívá klasických DNS serverů. Existuje základní doména e164.arpa, v níž jsou přidělovány čísla z mezinárodního veřejného telekomunikačního číslovacího plánu. Jednotlivé subdomény ITU deleguje příslušným státům (respektive oficiálním regulátorům stanoveným vládou daného státu) a ty dále delegují subdomény jednotlivým telekomunikačním providerům. Naše česká oficiální doména 0.2.4.e164.arpa je však zatím v jakémsi polotestovacím stavu.
Kromě oficiálního e164.arpa však vznikly i neoficiální ENUM stromy, např. e164.org, kde nad jednotlivými čísly mají plnou moc samotní uživatelé. A právě e164.org je využíván VoIP operátorem Like2Fone (přesněji řečeno e164.org a Like2Fone jsou spolu těsně provázáni). Dalším známým ENUM stromem je e164.info, kde mají svá čísla registrováni někteří VoIP operátoři (z českých opět např. VoIPEX).
Když budete mít nainstalovaný VoIP klient podporující protokol IAX, doporučuji také zaregistrovat se na VoipBuster.com (VoIP operátor umožňující 1 minutové hovory na pevné linky v mnoha zemích včetně ČR zdarma) a na MadaPhone.sk (slovenský VoIP operátor umožňující dokonce až 6 minutové hovory na pevné linky v několika zemích včetně ČR zdarma!). Když už tu máme služby zdarma, tak proč je nevyužít (alespoň dokud to jde ;-)).
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
echo "et.x86 0 0 direct" > /proc/asound/card0/pcm0p/oss echo "et.x86 0 0 disable" > /proc/asound/card0/pcm0c/ossDaval jsem je tam kvuli Quake 3 a jeste nejakym hram, u kterych jinak zvuk nefungoval (nepodporuji alsu a pokud toto neprovedu, hlasi ze nemaji MMAP pristup k /dev/dsp zarizeni). Mozna to ma vliv i na ten KPhone a Kiax, kdyztak to muzete zkusit...
Je tu ovšem i jiný otevřený protokol, který problémy s NATem nemá. Tím protokolem je IAX (Inter-Asterisk eXchange). ... (pokud jsou obě dvě strany za NATem, přímé spojení mezi nimi fungovat nebude)hm, tak já nevím, citované se imho navzájem vylučuje ... tedy pokud nám autor nechce říct, že to, že spojení fungovat nebude, problém není
kdyz ma NAT jedna strana, druha strana NAT nema a presto se nedomluvi, i kdyz spojeni iniciuje strana za NATem. To byl problem uz u H.323, ktery proste pri jakemkoli naznaku NATu prestal fungovat a je to zjevne problem i u SIPu,já pro změnu neznám implementaci jednotlivých klientů, nicméně SIP mechanismy k vypořádání se s NATem má; netvrdím, že IAX to nemá jednodušší, ale z hlediska uživatele lze dosáhnout stejné funkčnosti - článek mi tedy přijde velmi zavádějící v tom ohledu, že jako alternativu ke Skype zavrhuje SIP, ačkoliv jej lze použít stejně dobře ... otázky, co je ze síťového hlediska efektivnější a výhodnější, by vydaly na úplně jiný článek a myslím si, že by je autor (ani diskutéři) neměl tahat sem, mj. protože je to i otázkou vkusu, které výhody a nevýhody jednotlivých protokolů člověk preferuje - jestliže chce někdo argumentovat tím, že díky agregaci IAX ušetří polovinu pásma oproti RTP, který je využíván SIPem, mohu jako protiargument vznést otázku - a zahraju si po IAX šachy?
zavádějící v tom ohledu, že jako alternativu ke Skype zavrhuje SIP, ačkoliv jej lze použít stejně dobřeProsím? Já snad někde ve svém článku zavrhuju SIP jako alternativu? Nějak sem si toho nevšiml... V článku píšu mimo jiné např. "Nelze však říci, že SIP je oproti IAXu špatný protokol. Pouze naráží na problém současného rozšíření NATů.". Znamená to snad že SIP zavrhuju?
Super clanek, ale jelikoz zacina tim, ze bude uvadet alternativy ke Skype, myslim ze se tam jeste melo zminit jestli po prechodu na nektereho open klienta resp. pripadne s nekterym z free operatoru je nebo neni mozne nejak komunikovat s lidmi kteri zustanou u Skype.
Kdyby se z Jabberu nedalo komunikovat do site ICQ asi bych na nej taky jen tezko prechazel (a do dneska mam v seznamu jen jeden jabberovsky kontakt).
Samozrejme je tu moznost volani zdarma na telefon v CR coz je super - to by umoznilo jak zustat v kotaktu, tak zejmena presvedcit ostatni k prechodu. Ale stejne by moznost komunikovat se Skype kontakty primo byla minimalne prijemna.
A taky by me zajimalo, jestli si tedy s nekterou z alternativ pokecam nebo nepokecam z prace se zenou, kdyz jsme oba za NATem. Podle popisu protokolu to vypada jako ze ne, ale mozna to nektery klient nebo operator ma nejak resene, coz vsak uz v clanku neni zmineno. Skype to ma vyreseno sice zvlastne, ale ma...
Probůh, a jaký důvod může mít soudný člověk k tomu, aby si povídal s vlastní ženou?
Kdyby se z Jabberu nedalo komunikovat do site ICQ asi bych na nej taky jen tezko prechazel (a do dneska mam v seznamu jen jeden jabberovsky kontakt).jsem na tom stejně ...
A taky by me zajimalo, jestli si tedy s nekterou z alternativ pokecam nebo nepokecam z prace se zenou, kdyz jsme oba za NATem.zkus se zeptat těch, co tvrdí, že jim to funguje
Podle popisu protokolu to vypada jako ze ne, ale mozna to nektery klient nebo operator ma nejak resene, coz vsak uz v clanku neni zmineno.v případě SIPu to řeší proxy, buď se přes ní podaří dohodnout, jak se mají klienti zkontaktovat, anebo jde provoz přímo skrz ní
Člověče, píšeš, jako bys do SIPu investoval miliardy dolarů. Problémy se správným a exaktním vyjadřováním tu má kde kdo.
Takže abych to shrnul: SIP je v současné době používanější a existují pro něj jistá rozšíření, která mu pomohou dostat se i přes NAT (symetrický i asymetrický). IAX je novější, ne tak rozšířený, a je od počátku navržen tak, aby si s NATem poradil. Oproti SIPu má mít menší režii.
Mně osobně v tomto případě přijde menší režie mnohem podstatnější než rozšířenost SIP nebo Skype.
Např. v případě Jabberu to pro mě byla otevřenost, UTF-8 a Exodus.
Nebo je na IAX něco špatného? Chápu, že ti vadí, jakým způsobem se shazuje SIP, ale může nabídnout něco, co IAX ne? Já se také snažím vyvracet omyly ve svém okolí, ale že bych měl kvůli tomu potřebu někomu vrazit...? To už mi přijde jako nějaká fanatická zaslepenost.
Člověče, píšeš, jako bys do SIPu investoval miliardy dolarů.já ne
Nebo je na IAX něco špatného?to netvrdím (pravděpodobně by se něco našlo, ale nejsem znalcem IAX) - vadí mi to, že ... že se srovnávají hrušky a jabka, zhruba tímto stylem: článek je o ovoci, Skype jsou švestky, IAX jsou jabka a SIP jsou hrušky ... o švestkách se dozvíme, že je nemáme jíst, protože bychom se mohli zadusit peckou, o hruškách se dozvíme, že jsou na nic, že mají blbý tvar a blbou chuť a vůbec, a o jabkách se dozvíme, že je to to nejlepší ovoce, je úžasně kulaťoučké a chutná výtečně ...
Chápu, že ti vadí, jakým způsobem se shazuje SIP, ale může nabídnout něco, co IAX ne?jistě - třeba zahraju si přes IAX šachy?
Já se také snažím vyvracet omyly ve svém okolí, ale že bych měl kvůli tomu potřebu někomu vrazit...? To už mi přijde jako nějaká fanatická zaslepenost.hm, zřejmě jsi neviděl předchozí diskuse - v článku je prakticky to samé, co jsem předtím zkritisoval, to nejsou "problémy se správným a exaktním vyjadřováním", to je zcela záměrná desinformace!
Naopak jsem se snažil v článku nebýt jednostranný
Ten článek opravdu nebyl zaměřen proti SIPuMyslím, že všichni kromě kavola to viděli už při prvním čtení.
Thu Sep 22 11:29:43 2005 IaxWrapper::configureCall(acc number 1) configuring call..
Thu Sep 22 11:29:43 2005 IaxWrapper::configureCall(acc number 1) account number=1, account alias=freeworlddial
Thu Sep 22 11:29:43 2005 IaxWrapper::configureCall(acc number 1) callerId=r080
Thu Sep 22 11:29:43 2005 IaxWrapper::configureCall(acc number 1) callerIdNumber=703342
Thu Sep 22 11:29:43 2005 IaxWrapper::configureCall(acc number 1) codec=gsm
Thu Sep 22 11:29:43 2005 IaxWrapper::configureCall(acc number 1) filter flag=27
Thu Sep 22 11:29:43 2005 IaxWrapper::configureCall(acc number 1) silence threshold=-99
Thu Sep 22 11:29:43 2005 IaxWrapper::configureCall(acc number 1) devices in=0, out=0, ring=0
Thu Sep 22 11:29:43 2005 IaxWrapper::dial(int, QString) dialing 703342:xxx@iax.fwdnet.net/613 ..
Thu Sep 22 11:29:43 2005 IaxWrapper::event_state() processing IAX event..
Thu Sep 22 11:29:43 2005 IaxWrapper::event_state() call state 0 : active=1, outgoing=1, ringing=0, complete=0, selected=0
Thu Sep 22 11:29:43 2005 IaxWrapper::event_state() call info 0 : remote=613, remote_name=703342:xxx@iax.fwdnet.net/613, local=r080, local_context=default
Thu Sep 22 11:29:43 2005 IaxWrapper::event_text() Message: Type=1 Message=Call rejected by remote
Thu Sep 22 11:29:43 2005 IaxWrapper::event_state() processing IAX event..
Thu Sep 22 11:29:43 2005 IaxWrapper::event_state() call state 0 : active=0, outgoing=0, ringing=0, complete=0, selected=0
Thu Sep 22 11:29:43 2005 IaxWrapper::event_state() call info 0 : remote=613, remote_name=703342:xxx@iax.fwdnet.net/613, local=r080, local_context=default
Thu Sep 22 11:29:43 2005 IaxWrapper::event_state() INACTIVE 0