Kiax - plnohodnotná náhrada Skype?

19.9.2005 21:23 | Přečteno: 5110× | Linuxové báchorky

Zdravim

Nemám rád skype. Vůbec ho nemám rád. Všichni tu teď mluví o několika svobodných alternativách. Rozhodl jsem se teda nainstalovat si onen Kiax, co s ním, se uvidí pak.

www.linuxpackages.net - Results: 0

www.google.com -> http://kiax.sourceforge.net/

V download je posáno, že potřebuju jednak ten Kiax a pak knihovnu iaxclient http://iaxclient.sourceforge.net

Komu se podaří z výše uvedené stránky stáhnout alespoň byte zdrojáků, má u mě obdiv na jeden měsíc.

Na SF stránce se píše, že projekt zatím neuvolnil žádné soubory, dobrá, zkusím tedy CVS. Prvních 5 pokusů se nepodařilo, skončilo to na divné chybě při přihlašování, to byl vlastně důvod proč jsem tohle začal psát.

Ale teď už to stahuje, teď už i kompiluje iaxclient. Hotovo, výsledkem je soubor "libiaxclient.a". Co teď s ním? Make install neexistuje. Tak jsem ho ručně překopíroval do /usr/local/lib. Opravdu skvělé.

Dal jsem kompilovat kiax. Po spuštění ./configure to nic nenapsalo. Při pohledu na zdroják zcela nestandardního configure skriptu jsem usoudil, že je to asi v pořádku. Dal jsem make a teď čekám. Zkompilováno. První spuštění - tak a ještě to uživatelské jméno a heslo.

Takže já jsem kiax zkompilovat zvládnul. Otázka ještě je, zda skutečně bude fungovat. Ale skutečně má být kiax alternativou k Skype?

Zdeněk

       

Komentáře

[Jiří Jakeš]

Já jsem zase po té antiskypománii sáhnul po WengoPhonu a jsem velmi spokojen. Sice je linuxová verze zatím beta a distribuce balíčků není moc dobrá (oficiálně na stránce jen RPM a DEB), ale vše funguje, jak má. Doporučuji!

[Michal Čihař]

Eh, jaký je rozdíl mezi tím používat binární Skype a binární WengoPhone? Nějak mi uniká důvod přechodu .

[Jiří Jakeš]

Rozdíl je v tom, že binární WengoPhone je opensource Zdroják lze stáhnout...

[Michal Čihař]

Aha, to mají z toho, že na stránce pro download nabízejí jenom binárky .

[Zdeněk Štěpánek]

Na hlavni strance se pise: Sources available uner GPL license. Hned jsem si toho vsiml.

[Michal Čihař]

No když se mi natáhly obrázky, tak jsem to taky našel, ale na první pokus se načetly moc pozdě (ať žije blbnoucí připojení do netu ).

[Balda]

Ale vzdyt tam pisou, ze je to open source. ALe co me teda zarazilo je, ze ty balicky vyzdaduji distribuci s gcc 4.0.

[Jiří Jakeš]

Vyžadují gcc 4?

$ epm -qi gcc
Name : gcc
Version : 3.3.5.20050130
...

[balda]

wengophone ./wengophone: /home/xxx/OOo/program/libgcc_s.so.1: version `GCC_4.0.0' not found (required by ./wengophone) ./wengophone: /home/xxx/OOo/program/libstdc++.so.6: version `GLIBCXX_3.4.4'not found (required by ./wengophone)

[Mikos]

Pokud vím tak OpenWengo podporuje pouze SIP. Jak se tedy vypořádává se symetrickým NATem? Musí používat outbound proxy?

To je podle mě totiž největší výhoda IAXu - nemá za NATem problémy, kdežto SIP má problémy dosti velké (jistě, je tu STUN, nicméně ten v případě symetrického NATu nepomůže).

[kavol]

To je podle mě totiž největší výhoda IAXu - nemá za NATem problémy,

má - viz poslední věta tohoto příspěvku (doufám, že se mohu Danem zaštítit jako autoritou v oboru )

kdežto SIP má problémy dosti velké

proč neustále shazujete SIP? - jistě, v souvislosti s OpenWengo by měla být řeč o SIPu a o jeho nedostatcích, nemusíte se ovšem u toho tvářit jakože SIP je naho*no a IAX je božská spása ...

(jistě, je tu STUN, nicméně ten v případě symetrického NATu nepomůže).

a vysvětlíte už konečně, jak proti symetrickému NATu pomůže IAX?

- tedy prvně byste měl říci, co rozumíte jako "symetrický NAT", třeba jen mluvíte o koze, zatímco já se ptám na vůz ...

[Mikos]

Booože, člověče, vy jste strašně neúnavnej Kdy už si konečně uvědomíte, že těmi "problémy za NATem" samozřejmě mám na mysli problémy který se vyskytnou *kdykoliv* když je byť jedna jediná strana za NATem. Jsou dané tím, že SIP (stejně jako třeba H.323) je protokol svým způsobem podobný FTP, jenže narozdíl od FTP je u něj dosti obtížný connection tracking (sice již existují nějaké experimentální patche na iptables, které umožňují SIP conntrackovat, ale to není standardní záležitost).

Je zcela logické, že pokud jsou obě dvě strany schovány za NATem, nemůže mezi nimi být provedeno přímé spojení. Vubec sem netušil, že si snad můžete myslet něco jiného, tak to "vyhnutí se problémům s NATem" opravdu myšleno nebylo. V takovém případě se prostě musí použít proxy. Ani Skype není v tomhle nijak zázračná - pokud jsou obě dvě strany za NATem, běží pak komunikace přes nějakou neznámou třetí osobu (která o tom navíc nemusí mít vubec tušení). To je zcela stejná situace jako v případě použití proxy serveru.

[Ctirad Feřtr]

Je zcela logické, že pokud jsou obě dvě strany schovány za NATem, nemůže mezi nimi být provedeno přímé spojení.

Dovedu si představit, že by se do klientů dala zamontovat finta jakou používá chownat. Pak by stačil nějaký "HUB" s veřejnou adresou, který by akorát vyrozumněl oba klienty o adrese NATu protistrany a ti by se pak spojili přímo díky výše uvedené fintě. Tím by proxy odpadla, respektive zredukovala by se na něco, přes co se jenom dohaduje spojení a nežere skoro žádnou konektivitu.

[Mikos]

O tom projektu chownat slyším poprvé, zajímavá věc, díky za informaci. Něco takového by pravda mohlo fungovat. Ovšem příjde mi, že je to svou funkcí obdobné protokolu STUN, který je již v SIP klientech na obcházení NATu běžně používán, ale se symetrickým NATem si neporadí. Jaktože tohle si má poradit i se symetrickým NATem? Jaké jsou rozdíly mezi fungováním chownatu a STUNu?

Jinak bohužel existují i NATy, s kterými si ani chownat nemůže z principu poradit. Např. některé NATy vestavěné do ADSL routerů přiřazují porty pseudonáhodně a tím pádem nevíte jaký zdrojový port budou mít vaše odchozí UDP pakety a tedy ani protější strana neví kam má UDP pakety posílat. Prostě jsou NATy s kterými se člověk bez třetí strany (ve formě proxy serveru) bohužel neobejde

[kavol]

Dovedu si představit, že by se do klientů dala zamontovat finta jakou používá chownat.

jsem líný hledat, co je chownat, nicméně -

Pak by stačil nějaký "HUB" s veřejnou adresou, který by akorát vyrozumněl oba klienty o adrese NATu protistrany a ti by se pak spojili přímo díky výše uvedené fintě. Tím by proxy odpadla, respektive zredukovala by se na něco, přes co se jenom dohaduje spojení a nežere skoro žádnou konektivitu.

to je přesně to, jak to může řešit SIP

... bohužel takovéto řešení nefunguje vždy

[kavol]

Booože, člověče, vy jste strašně neúnavnej

přece nenechám někoho šířit blud ... :-p

neustále opakujete různá tvrzení na téma, že IAX narozdíl od SIPu NAT řeší - což je konina, jednak to navozuje dojem, že IAX je možno použít libovolně za NATem, což není pravda (jak má náhodný čtenář tušit, které situace z toho vylučujete, zvláště když jste to napsal teprve v předchozím příspěvku, reagovat na mé předchozí přímé dotazy adekvátním způsobem jste se neobtěžoval?), a jednak to navozuje dojem, že SIP za NATem použít nelze, což také není pravda (ostatně sám zmiňujete STUN)

[Mikos]

Jediný kdo tu neustále šíří bludy jste vy, když se neustále snažíte všude možně předhazovat, že šířím bludy já.

IAX skutečně za NATem má z principu méně problémů než SIP, to jsou holá fakta. Stačí si přečíst RFC k protokolu STUN jestli mi stále nevěříte. Např. v případě, kdy jedna strana je za NATem s kterým si STUN neporadí, ale druhá strana má veřejnou IP, tak si spolu v případě použití SIPu stejně nepopovídají. U IAXu by ovšem neměli v takovém případě žádný problém.

Já nikde neuváděl, že IAX je dokonalost sama, i v mém článku o VoIP jasně píši, že IAX problém NATu nijak zázračně neřeší, jen je prostě v tomhle na tom lépe než SIP. Má proti SIPu i další výhody (např. lepší využití šířky pásma), ale i nevýhody (jako nevýhoda se z určitého pohledu může jevit právě i to, že slučuje signalizaci a datový kanál do jednoho... nebo že se jedná o binární protokol oproti textovéu SIPu). Rozhodně ovšem SIP jako protokol nikde nijak nezavrhuju, je to dobře navržený protokol a má budoucnost.

[Kamik]

V takovém případě jakýkoliv program musí použít "proxy" s veřejnou adresou minimálně k navázání spojení. Řešení je potom pouze na použitém software, jestli umí nebo bude umět zabalit problematický SIP či jiný protokol třeba do ssl tunelu mezi oběma účastníky.

[Michal Vyskočil]

Tohle je záležitost distribuce. I když pochybuji, že by Patrik přidal Kiax do Slackware , což je jeden z důvodů, proč už Slacka nepoužívám. Jinak

time emerge kiax
...
real    4m53.089s
user    2m46.955s
sys     0m15.699s

[Spike]

Taky jsem kiax emergnul... Ale ještě nepustil. Co teď? Předně bych mohl někde vyštrachat mikrofon, zapojit ho a zprovoznit, což by neměl být problém. Průšvih asi bude ozvěna způsobená reproduktory...

Beztak bych ale raději viděl Jabber klienty implementující (v současné době neexistující (?)) JEP pro hlasovou XMPP komunikaci. Nějak se mi nechce používat na IM něco, co není (čistokrevný) Jabber klient.

Tak mě napadá, nemá někdo zkušenosti s BlueTooth headsety pod Linuxem? V horším případě i normální USB, no, ale ten BT bych mohl, předpokládám, využít i s mobilem. (Resp. BT handsfree bych použil pro VoIP)

[Dan Ohnesorg]

Ano zkousel, krome problemu se VoIP klienty vam jeste pribudou problemy s alsou

Ale vazne chodi to. Chodi to o mnoho lepe nez repraky a mikrofon, ale konfigurace je opravdu pro hracicky.

[Spike]

Máš na mysli BT nebo čistě USB? V každém případě to je přesně pro mě... ^_^

[Dan Ohnesorg]

Ne mam na mysli BT, mam takovy ten BT nesmysl do ucha a BT adapter do USB portu. Po nejakem delsim googlovani a naslednem jeste delsim kombinovani jader, alsy, obsahu .asoundrc a tak podobne jsem dokazal pustit inet radio do sluchatka a nahrat to co jsem rikal. Potom uz staci jen naucit Xten, kphone (brutalne nestabilni) ci neco jineho, aby to slo na patricne /dev/* zarizeni a da se telefonovat.

Veci jako zvedani hovoru tlacitkem na ousku jsem ani nezkousel.

Mimochodem, kdyby nekdo chtel udelat clanek-popis toho co se muze davat do asoundrc, jak to kombinovat a artsd a tak dale, tak by mel jiste zarucenu nehynouci slavu. Zda se mi, ze je to ponekud nezdokumentovane.

[kavol]

hm, záležitost distribuce ...

# emerge -av kiax

These are the packages that I would merge, in order:

Calculating dependencies
!!! All ebuilds that could satisfy "kiax" have been masked.
!!! One of the following masked packages is required to complete your request:
- net-misc/kiax-0.8.4 (masked by: ~amd64 keyword)

For more information, see MASKED PACKAGES section in the emerge man page or
section 2.2 "Software Availability" in the Gentoo Handbook.

... ale na druhou stranu:

# urpmi kiax
Je zapotřebí jeden z následujících balíčků:
 1- libilbc0-0.6-1mdk.i586 : Internet Low Bitrate Codec (iLBC) library (to install)
 2- libkcall0-0.5.2-1mdk.i586 : Librairie files for kcall (to install)
Jaká je vaše volba? (1-2) 2
Aby byly splněny závislosti, budou nainstalovány následující balíčky (celkem 6, 2 MB):
kiax-0.8.4-2mdk.i586
libgsm1-1.0.10-9mdk.i586
libiax0-0.2.3-8mdk.i586
libiaxclient0-1.0-0.20050410.3mdk.i586
libkcall0-0.5.2-1mdk.i586
libportmixer0-18.1-2mdk.i586
Je to správně? (A/n)

[Ctirad Feřtr]

V x86 gentoo maskovaný není.

[kavol]

to nebylo myšleno proti Gentoo - jen mě Michal pobavil, že Slacka ne a Gentoo jo

[Mikos]

Tedy já Kiax používám a jsem si na 100% jistý, že iaxclient (ani žádné jiné podobné závislosti) neměl. Když kouknu do balíčků se zdrojákem, jsou kromě Qt uplně všechny potřebné knihovny (iaxclient, zvukové kodeky, atp.) přiloženy. Sice šťastnější řešení by možná naopak bylo, kdyby přiloženy nebyly (je to více *nixové - nemám rád staticky zkompilované programy ), nicméně vaše problémy tímto padají - žádný iaxclient kompilovat nemusíte.

[Jiří P.]

a co treba kphone?

[Zdeněk Štěpánek]

Zdravim

Kphone jsem zkousel taky, je to klient pro SIP. Mam ho zkompilovanej doma, ale k ustredne kterou jsem zkompiloval u sebe na serveru (siprouter) se proste nepripojil, tak jsem ho nechal plavat.

Zdenek