Neni ani tak problém vybrat a zatelefonovat si když má člověk veřejnou ip adresu. Jak je to ale v zanatovaných čechách? Jak se řeší průchod sipu přes nat? Jak se to řeší třeba přes linuxovou maškarádu? To je hlavní překážka která brání začít telefonovat.
nekteri provideri to resi nejakym transparentnim stunem, ktery naty projde, viz treba 802.cz, ktera beha za natem v pohode. mozna nekde problemy jsou, tomu verim, ale zatim jsem mel (tuk, tuk, tuk na drevo) stesti
Tak sipproxd je podle mych zkusenosti na nic, kdyz se chces prihlasit k providerovi.
Co ale spolehlive funguje, je sip traversal z netfilter.org. Drzi mi stabilne.
Jinak sip klientu jsem zkousel celou radu, ale nakonec jsem zustal u xtenu. Ma vsak problem - hada se o zvukovou kartu s artsd, takze kdyz chci telefonovat, musim artsd killnout.
Takovych demonu netreba. Sracky jedna jako druha. Na nic. Kdysi kdyz bylo voip jeste v plenkach zkousel jsem telefonovat z nejaky vibry 16x coz je klon sb16. Ten urcite hw mixing nemel. Tyhle revizi fungoval i full duplex narozdil od predchudkyne. No a ta ISAcka zvukovka jela s telefonovanim bez problemu. Normalne pres OSS. Tak jakypak demoni. artsd bylo a je akorat vzdycky problematicky.
Například u SIP Express Routeru (SER) se to řeší ze strany serveru, protože ne všechny klienti mají dobrou podporu pro překlenutí NATu. STUN podpora ne vždy funguje a je nespolehlivá. Téměř stoprocentní překlenutí NATu zaručuje RTP proxy, ale nevýhodou toho je, že při komunikaci vznikne zpoždění a to ještě nemluvím co by se stalo, když RTP proxy má špatnou konektivitu (špatná kvalita přenosu, velké zpoždění atd.)
Tím pádem se administrátoři snaží nakonfigurovat SER tak, aby co nejméně používal RTP proxy. SER má totiž modul jménem NAThelper, který pomáhá překlenout NAT pro klienty.
Nebo taky by se mohl začít používat ICE, ale ten je velmi složitý a zatím v plenkách tzn. nemá podporu v klientech.
V podstate mate pravdu. Vlastne jsou bezne pouzivane jen dva zpusoby "boje" s NATem:
1. klient si musi sam zjistit verejnou IP adresu brany a udrzovat spojeni na brane - k tomu je urcen STUN server (pomuze klientovi zjisti IP a udrzuje mu spojeni)
2. vse se pokusi resit "pohledem z okna" VoIP operator - outbound proxy. Proste operator kasle na to, co mate napsano v SIP hlavickach a posila komunikaci na IP adresu odkud k nemu prichazi a dokonce muze i pomahat v udrzovati spojeni pro rtp streamy...
1. STUN nepomuze ve vsech pripadech. Kdyz v ceste je symetricky NAT potom nezbude nic nez pouzit RTP proxy. Nebo zeby server vedel, ze druhy klient s verejnou IP umi symetricke RTP tak potom by mohla byt komunikace bez RTP proxy.
2. ano to je pripad co jsem uvedl v 1. a i v predchozim prispevku
Nechci se dohadovat o slovickach, ale prijde mi, ze v "branzi" vzity nazev je outbound proxy - zejmena proto, ze s RTP proxy nema nic spolecneho :-) RTP proxy (tedy ten modul ze SERu o nemz mluvite) je jen malou soucasti outbound proxy. Ta totiz nehandluje jen s RTP streamy, ale i se SIP signalizaci (a vetsinou funguje take jako registrar :-)
STUN samozrejme neni vsemocny...
kokoska.rokoska
BTW: Pasovani SERu to role toho jedineho spravneho mi pripada prinejmensim posetile :-)
Je pravda, ze jsem vice zameren SER a o ostatnich projektech moc nevim.. Vlastne se stale ucim a vypada to, ze toho vite vic jak ja. Jen sem chtel nastinit jak se to dela se SERem a tim objasnit jeden zpusob pristupu k problemu.
OK chapu. A vice nez Vy toho asi nevim, jen jsem se obcas kolem neceho podobneho mihnul a taky se stale ucim :-)
kokoska.rokoska
BTW: Budte rad, ze SER je Vasim kamaradem - takovych lidi je VELMI malo. Slusna konfigurace SERu (vcetne zminovane RTPproxy) neni zrovna jednoducha vec - narozdil od Asteriska, jehoz do provozuschopneho stavu uvede kazde kopyto (vcetne me :-)...
