Chtěl bych se na tomto místě zeptat zda někdo neví zda je pro soukromníka s jednim telefonem lepší přejit na VoIP nebo si nechat analog. A zda by mu tam šel i FAX.
Cez VoiP (SIP) by prenos FAXu mal fungovat za predpokladu pouzitia G711 bez potlacania ticha, ale prakticky je prenos velmi nachylny na chyby.
Alternativou je T38 Protokol. Ten musi ale podporovat poskytovatel a musi byt podporovany aj vo VoiP zariadeni.
Takze ak je pre teba cenovo vyhodnejsi VoiP a poskytovatel podporuje aj T38 prejdi na VoiP.
Řešíme to v naší firmě. Stávající čísla lze převést k VOIP operátorovi (bohužel si za to telekomunikační úřad bere pár tisíc). Příchozí fax přes VOIP operátora - zasílá nám mailem v PDF, velice praktické pro následnou distribuci ve firmě. Odchozí faxy lze také přes VOIP, ale to se musí skenovat, takže zatím používáme standardní analogové faxy.
No, fax se da vyresit nejaou fax sluznou, pak posilate a prijimate mailem.
Ale neni to zadarmo, tusim ze je to vetsinou pausalizovane (kredit).
Osobne jsem se jeste nesetkal se spolehlivym faxem over IP.
Ja taky prechazim na VoIP. Uz se mi podarilo rozchodit Dlink router v rezimu switch, treba se mi podari i rozchodit ten VoIP telefon co jsem dostal darkem (Grandstream) a daa-li buh, nebude se dit takove co se vecne deje bratrovi, ze nekdo zavola, clovek to zvedne, ono je to mrtve, tak to polozi, za chvili se zavolani opakuje a zase to same a asi 3x.
Grandstream je poměrně mizerný telefon. Pokud budeš mít problémy, vyzkoušej jiný. Já jsem přešel od nějakého čínského krumplu založeného na Centrality chipsetu na Snom 190 a je to nebe a dudy.
Osobne pouzivam Linksys WRP400 + DECT telefon (obycejny Sencor), jako operatora 802.cz s nomadickym cislem. VoIP pouzivam ve Vidni, kde mam pripojeni od UPC, na volani z/do CR. V provozu zatim asi 1/2 roku a nezaznamenal jsem problem.
S chvalou na 802.cz se musim pripojit. Mam to doma a take si nemuzu stezovat. Dokonce mit o funguje pres bezdrat od O2 v Praze (coz je docela peklo, protoze zatizeni site mi ani v tom nejmene vytizenem case neumozni dostat se na tretinu rychlosti).
Navic maji akci za predplaceny kredit zarizeni zdarma.
P.S.: Jedine problemy ktere zaznamenavam je volani na automaticke linky, kdyz treba pres to mate opsat cislo kreditni karty, tak to neprojde, proste ten signal je trochu rozbity, coz cloveku nevadi (a pokud je to par cisel tak ani stroji), ale 16 mistny kod mi to jeste nikdy neschroustlo.
Ako maju byt nastavene iptables, aby som mohol pouzivat SIP (pripadne aj H.323) bez pouzitia STUN serveru? Zatial sa mi vzdy stalo, ze ked som pridal moduly nf_nat_sip a nf_conntrack_sip), tak to nefungovalo vobec
Moje VoIP krabička umožňuje nastavit veřejnou IP a pak SIP port i RTP port. Na bráně do Internetu pak mám nastaveno jen přesměrování (dnat) příslušných portů na ty samé porty na IP VoIP krabičky. Funguje to dobře - prostě se to jeví jako by VoIP krabička byla přímo v Internetu a ne za NATem.
Problém je ovšem v tom, že pak není možné volat ve vnitřní síti za NATem přímo z jednoho VoIP zařízení na druhé (na IP adresy vnitřní sítě a příslušné porty). Sice to zvoní, ale přenos hlasu pak nefunguje, jelikož to neposílá hlas na interní IP, ale na tu veřejnou a přesměrování portů na bráně je připraveno jen na provoz z Internetu.
v pripade ze jedna strana NATu je na verejnej IP a vnutro je tvoja lokalka kde su aj SIP zariadenia tak tie moduly a jednoduchy maskaradovy NAT napriklad v style http://www.gentoo.org/doc/en/home-router-howto.xml je vsetko co potrebujes ku stastiu
isty vplyv na to moze mat nastavenie toho, co si o type NATu mysli telefon ale s tymito modulmi by malo stacit aj najjednoduchsie "public IP"
[intro]
Myslim, ze VoIP neni budoucnost, ale jiz dlouho soucasnost. Naprosta vetsina velkych spolecnosti na VoIP jiz davno presla, stredni spolecnosti zacaly prechazet v prubehu minulych par let a nyni se "dostava" i na ty nejmensi a potazmo na "retail" :-)
[/intro]
Ac si velice vazim jakychkoliv clanku popularizujicich VoIP, tak u teto agitky se obavam, ze celemu VoIP prokazujete medvedi sluzbu, pane kolego Semane :-)
Na mnoha mistech totiz (urcite v dobre vire) matete potencialni nove uzivatele. Mozna to nekomu pripada jako marginalni problem, ale ja bych presto nektere teze poopravil:
1. U hovoru z Prahy do Bratislavy s vyuzitim "bezneho VoIP operatora" vetsinou hovor nepotece celou dobu pres internet, ale pouze od uzivatele k operatorovi a dale bude pokracovat po TDM (E1 s SS7), protoze jenom tak je operator schopen garantovat paramerty spojeni vyzadovane platnou legislativou.
2. Uznavam, ze "SIPovska" RFC patri k tomu nejhorsimu, co kdy v IETF vzniklo, ale to nic nemeni na faktu, ze v realnych implementacich prochazi SIP NATem jak nuz maslem. Jedine, co tomu obcas brani, je snaha vyrobcu noname routeru o implementaci SIP ALG. A tez snahy uzivatelu nastavovat na routerech ruzne "port forwardy", nacitat SIP ALG "prasarny" do iptables...
3. Nedovedu si predstavit, jak by H.323 mohl zajistit QoS :-) To prece musi udelat router. A ten to muze udelat pro jakykoliv provoz (treba SIP+RTP :-).
4. IAX je tu s nami jiz peknych par let a stale slycham jak je skvely a zachvilku ovladne scenu VoIP. A porad nic :-) A jsem si prakticky jist, ze tomu tak bude i nadale.
Nejvesti problem IAXu (krome toho, ze ho nikdo nepodporuje) je prave svazani signalizace se samotnymi hovorovymi daty, coz automaticky znamena spatnou skalovatelnost. Pokud chcete pouzivat jeden server pro dva lidi, neni to problem, ale pokud jich chcete obsluhovat vice, mate smulu. Zatimco u SIPu (venkoncem tato koncepce je "prevzata" z SS7) muzete pomoci loadbalnceru, samostatnych registraru, proxy serveru a RTP forwarderu vytvorit sluzbu pro miliony uzivatelu (napr. 1und1 s 2,4 mio klientu) tak u IAX skoncite na par stovkach - protoze vsechna data (vcetne hovorovych) musi prochazet pres vstupni bod do vasi site (Asteriska).
A rad bych dodal, ze ta vyhoda s NATem je tez velmi pofiderni (jedina skutecna vyhoda je, ze vzhledem k zanedbatelne rozsirenosti jeste zadneho vyrobce routeru nenapdalo implementovat neco jako IAX ALG :-). Vetsina problemu s NATem je zpusobena malou informovanosti uzivatelu (vcetne spravcu siti) o spravnem zachazeni s connection trackingem na routeru. Neuvedomuji si totiz, ze se jedna o UDP provoz (SIP+RTP i IAX), a meni pravidla na routeru (a restartuji, vypinaji...) aniz by conntrack nejdrive vypnuli a zapnuli ho az po uspesnem nacteni vsech zmen.
5. Prohlaseni, ze moznosti Asteriska jsou neomezene, je hodne nadsazene i v takto popularizujicim clanku. Ac mam Asteriska pomerne v oblibe, je nutne rici, ze jeho moznosti jsou velmi omezene. Jak vykonove, tak kvalitou implementace (treba chan_sip je fakt hruza) vlastnosti, o celkovem designu (a, oblibene deadlocky) ani nemluve.
Tim nechci tvrdit, ze je nepouzitelny, ale pri jeho pouzivani musi byt clovek hodne obezretny a musi se pripravit na to, ze jeho nejlepsim pritelem se stane vi/vim/emacs/... a gcc :-)
Aby muj prispevek nevyznel zbytecne negativne, tak znovu podotykam, ze VoIP je zcela bezny a kvalitni zpusob komunikace, obzvlaste v byznys sfere velmi rozsireny, a cenove dostupny i pro jednotlivce. A s Asteriskem se nakonce taky "da prezit" :-)
vazim si Vasich pripomienok , ale pochopte prosim ze tento server sa zaobera predsa len Linuxom a VoIP nie jeho "nosna" tema ,preto sa snazim clanok urobit co najviac otvoreny pre nasledujucu diskusiu a Asterisk vnimam ako jeden zo spojovacich bodov medzi svetom VoIP a Linuxom. Clanok mal len jediny ciel informovat, ze VoIP je jasna buducnost a netreba sa jej bat. Preto by som rad uzavrel tuto temu s Vasim poslednym odstavcom :-)
p.s. z odborneho hladiska Vase pripomienky plne akceptujem a su myslim nie len pre mna potesenim ich citat, nakoniec Vasa nezistna pomoc na fore server telefonujeme.cz bola a je pre mna vzdy velkym prinosom , za co sa Vam chcem aj touto cestou podakovat. S QoS na H.323 som sa sekol a dakujem za opravu :-)
Zamereni serveru si uvedomuji a plne respektuji :-) A velice nerad bych, aby muj predchozi prispevek vyznel jako vytka vuci Vasemu clanku. Tak to vubec nebylo mysleno! Vasich clanku na rootu si vazim, ctu je peclive a jsem velmi rad, ze se zde objevuji (a je dobre, ze pisete slovensky - nenechte se stizniky odradit). Jenom jsem chtel dodat par drobnosti...
Co se týče výhod a nevýhod IAX. Podle mě hlavní výhoda IAXu je, že pokud je trankovaný, vyžaduje podstatně nižší datový tok (téměř polovinu) oproti stejným hovorům posílaným ve stejném kodeku přes SIP !!! Pokud si kupujete garantovaný internet je to podstatná úspora.
Myslím že IAX škálovat jde, jen se to musí dělat jinak. Můžete IAX škálovat využitím více IP adres pod jednou doménou, využitím více domén (adres), nebo z jedné adresy přeroutovávat na více Asterisků ... I když to není tak pěkné.
Parametry spojení může oparátor garantovat (ale nemusí dodržet) při jakémkoli spojení. I hovory přes SS7 mohou být velmi nekvalitní. Přímé VoIP propojení, bývá obvykle velmi kvalitní, je-li kvalitní internetové spojení, navíc je bez prostředníků, které mohou hovor dále kazit (např. se rozhodnou hovor na Slovensko směrovat přes USA, čímž zvýší minimálně zpoždění). Je pravda, že o SS7 skoro nic nevím, zato znám více firem co "dělají machra" že to směrují přes SS7 a je to mizérie :)
1. Rad bych se zeptal, zda jste jiz "trunkovani IAX" zkousel. Pokud ano, tak me prekvapuje, ze o nem muzete cokoliv jineho nez nepublikovatelne vyroky :-)
Ono uz z principu se snazit multiplexovat hovorova (a nedej boze jeste navic komprimovana) data do jednoho "kanalu" neni zrovna rozumne (latence, jitter, spotreba zdroju), takze prilis neprekvapi vysledek. Schavlne zkuste takto multiplexovat aspon 10 kanalu (a lepe vice) a merte jitter a zatez stroje. A kdyz k tomu nahodou nebudete mit opravdovy casovac (Sangoma karty), ale ztshit, pardon, preklepl jsem se, ztdummy, tak to teprve bude krasa.
2. A IAX skalovat opravdu nejde :-) U slusnych VoIP operatoru existuje prave jeden bod vstupu do site. Rozklad pomoci DNS (round robin, SRV) pouzit nemuzete, mate-li klienty za NATem, protoze musi dostavat packety od toho Asteriska, ke kteremu se registruji. A spolu se signalizaci jdou i data.
3. Zajimalo by me, jak by mohl operator garantovat parametry spojeni na linkach, nad nimiz nema uplnou kontrolu :-) A u verejne telefonni sluzby je musi dorzet, ba dokonce dodrzovat. Doporucuji ke shlednuti Zakon c. 127/2005 Sb. vcetne provadecich vyhlasek. Zbytek nebudu komentovat.
Jeste bych se "ze zvedavosti" zeptal: Mohl byste prosim (treba soukrome, neni-li to zverejnitelene) jmenovat nejakou firmu tvrdici, ze vse "smeruje pres SS7" a je to mizerie?
1. Ano zkoušel jsem trankovaný IAX i na 20 hovorech, na žádné zjevné potíže nenarazil, takže neměl nutnost měřit nějaké parametry. Fakt je, že možnost si snížit datový tok na polovoninu snad i za cenu zvýšené zátěže se může někdy hodit. Na druhou stranu, pokud z toho není zjevný prospěch, je asi dobré se tomu vyhnout.
2. Stačí nesouhlasit s větou "U slušných VoIP opetrů exituje právě jeden bod vstupu do sítě." a mám IAX bez problému škálovatelný. Když nemám jeden bod vstupu nemám jeden bod of failure. Jde jen o to to udělat tak, aby to zákazníka neobtěžovalo, nebo nejlépe aby si toho vůbec nevšiml. Co takhle říct, že se bude přihlašovat na doménu ve tvaru id_zakaznika.moje_domena.cz a mám vyškálováno pomocí DNS serverů. Nejlepší samozřejmě je pokud zákazník údaje jako doménu nebude nikam zadávat, vše se nakonfiguruje automaticky. Jiné řešení je přeroutovávat, problém ale je že musím přeroutovávat ohromné množství dat, nikoli jen signalizaci. (Z adresy A přeroutuji vždy na sterisk C) Argument "u slušných VoIP operátorů" neberu, slušné je to co je jednoduché a funguje. Jistě by se dali vymyslet i jiné možnosti. Faktem ale je že cesta RTP streamů v SIPu se dá lépe naplánovat, může být tedy přímější.
http://www.sagit.cz/pages/sbirkatxt.asp?zdroj=sb05127&cd=76&typ=r
3. Podle mne, garantovat se dá jedině smrt. Proč z pohledu zákona mohu používat VoIP vnitrostátně, ale mezistátně je to problém? Svého času měl O2 problémy s hovory do Mongolska a nebyl schopen to vyřešit ani přes opakované urgence. Buď tedy nepoužíval SS7 na celou trasu, čímž se dostal na úroveň VoIP operátora co podle vás porušuje zákon, když směruje hovory na Slovensko přes VoIP a nebo mu v tom SS7 nepomohlo. Jistě se najde více destinací s kterými má potíže, nikomu se to ale nechce za 40 Kč/min a více moc zkoušet :) Jistě je na zemi spousta destinací, kam se garantovaně dovolat vůbec nedá. A co říká český zákon na to, že pevné linky v Bagdádu poté co tam Amaričani začali dělat pořád téměř nefungují? Přijde mi to docela nechutné co se všechno český úředník nesnaží regulovat. I když jasně to má to určitě svou logiku i argumenty.
Ad 2. Vami popsane reseni, bohuzel, skalovatelnosti nijak nepomuze. Aby to fungovalo, musel byste zaridit, ze uzivatele registrovani k jednomu Asteriskovi si budou volat jen mezi sebou (a nikoliv uzivatelum na jinym Asteriskach) a navic, ze uzivatele registrovani na kazdem Asterisku budou generovat zhruba obdobnou zatez, coz IMO take nezaridite.
A pokud nezajistite predchozi pozadavky, pridani dalsich stroju zvysi propustnost Vasi telefonni site maximalne o jednotky procent a mnohdy take vubec (a zahy narazite na problem s jitter a latenci - takze se situace s vetsim mnozstvim stroju spise zhorsi)
BTW: Zadny z techto problemu u protokolu s oddelenou signalizaci a "hlasovymi data" neni (SIP, SS7).
Ad 3. Proctete se zminovane dokumenty, tam nikde neni psano, ze VoIP lze pouzivat vnitrostatne :-) Jakakoliv regulacni opatreni musi byt (pokud to je mozne) technologicky neutralni. Tudiz provozovatel verejne telefonni sluzby musi garantovat maximalni latenci na jednotlivych castech sve site s tim, ze musi zaroven s ostatnimi propojenymi operatory garantovat maximalni latenci celeho spojeni. A je jedno, zda jde o VoIP ci TDM. A jelikoz na "verejnem internetu" se neda garantovat nic, ma vetsina VoIP poskytovatelu definovan jako koncovy bod site vnejsi rozhrani jejich routeru (cimz vypadava internet ze hry) a interne vse "posila" po TDM.
Obdobna pravidla plati ve vetsine ostatnich evropskych zemich, takze se vubec nejedna o ceskou specialitu. Jinak, celkem pochopitelne, narodni regulator muze regulovat pouze deni na uzemi prislusneho statu.
Zkratka a dobre, kazdy operator musi zajistit kvalitu vyzadovanou loklani legislativou (ktera byva v jednotlivych evropskych zemich obdobna) a dosahnout celkove kvality dostatecne pro svoji cilovou skupinu pri zachovani odpovidajici ceny.
Takze - budete-li provozovat sit pro "kolenovrty", tak Vam zrejme bude stacit vejit se do zakonnych pozadavku. Naopak, pokud se budete soustredit na podnikovou sferu (kde kazda vetsi firma vybira operatory ne podle ceny - tu jim nabidnou vsichni prakticky stejnou - ale podle kvality site; viz automaticky monitoring SS7), muzete na zakonne pozadavky zapomenout, neb po Vas klienti budou zadat o rad vyssi kvalitu.
Suhlasim v podstate s oboma nazormy ale zaroven si myslim ze tu sa stretli dve rozdielne nahlady a to pohlad poskytovatela verejnej telefonnej sluzby a uzivatela VoIP technologie . Pre poskytovatela je IAX naozaj nepouzitelny pokial garantuje verejne tel. sluzby a bolo by navyse neseriozne ak by vyhlasoval , ze IAX nie je problem. On to problem je prave z hladiska vyssie zmienovanych dovodov, ktore opisal kolega kokoska.rokoska. Preto aja mna by z rovnakeho dovodu zaujimalo , ktory operator moze prehlasit ze signalizacia SS7 je mizeria , bud v tom nema jasno alebo je proste neseriozny. Ano aj ja som sa stretol v praxi , ze rozne firmy ktorych mena vznikaju a zanikaju ako huby po dazdi zacali bez problemov poskytovat IAX na ich strane a ten IAX aj funguval ked tam bola prevadzaka cca. niekolko desiatok hovorov, ale co ak ta prevadzka narastie ? A preco ta firma, ktora to vyhlasovala uz nie je na trhu ?
Druhy pohlad je tiez v podstatne spravny , ono nie je nic lepsie ak Vas poskytovatel VoIP sluzieb rozumie svojej praci a navrhne svojmu klientovi aj kvalitne a a hlavne prevadzky schopne riesenie. Ak operator navrhne pristup do svojej siete cez IAX protokol , tak ze na strane klienta bezi asterisk s primeranym "zelezom" s dostatocnou sirkou pasma a vsetky hovory smeruje cez jeden alebo viac IAX trunkv do svojej siete ,tak to robi preto lebo vie ze trafic klienta nepresiahne kriticky bod a tuto prevadzku bude schopny garantovat. Potom je naozaj zakaznik spokojny a nema preco IAX protokol zatracovat.
Ak Vas ale operator zacne presviedcat , ze IAX je to prave a vsetko ostatne je mizeria a len tak spomenie signalizaciu SS7 (o ktorej aj tak nic nevie) , tak je to bud "optimista" , ktory si v garazi nainstaloval Asterisk a a v exceli si spocital zisk (ved je to take lahke :-) ), alebo je to proste nekvalifikovana informácia obchodníka-novacika, ktory obsalovoval prve skolenie a bol poslany do terenu ...
1.) Ne kazdy ma tu smulu se pohybovat na zapraskanejch linkach :-). IAX trunking mezi dvema ustrednami je opodstatneny prinos. Jednak se snizi traffic nekde vic nez o polovinu a druhak klesne nutny pocet prenasenych paketu (coz je na nekterych sitich take zlepseni).
ztdummy uz davno neni takovej shit jak to byvalo s RTC casovacem. S prichodem HIres timeru v jadre a implementace do ztdummy je tento casovac dostacujici kvality. Nicmene pokud je to synchronizovano primo z TDM, neni o cem mluvit.
IAX2 trunking jede velmi spolehlive. Bezproblemovy rocni provoz 30 kanalu mezi dvema ustrednami usetril gigabajty dat (a to nemluvim o snizeni zateze zmensenim poctu prenasenych paketu z 3000 na 100 za vterinu). Driv na IAX2 byvalo hodne deadlocku (hlavne 1.4). Asterisk 1.2 (hlavne ke konci jeho zivota) uz nemel problem. Nicmene na asterisku 1.4 bych se bal vubec IAX nasadit na vetsi provoz. Mozna je to ale uz vyladene. Navic, IAX2 implementace v asterisku je jeste horsi monolit, nez implementace SIP kanalu.
2.) S vetsi fantazii to lze prekonat. Umim si to predstavit tak, ze mam vice serveru a pro klienty jedinou DNS pristupovou adresu. Na routeru je rozhazuju firewallem napriklad tak, ze podle zrojove adresy je odkazu na patricny server. Ale uznavam, ze skalovatelnost SIPu diky oddelenemu prenosu hlasu je mnohem snazsi a systemovejsi.
Ad ztdummy: ze se zlepsilo, to uznavam, ale stale IMO stoji za prd. Obzvlaste srovnam-li to s tez SW "casovanim" treba i FreeSWITCHe. Jinak nezbyva nez souhlasit, ze do Asteriska jsou externi hodiny zasadni.
BTW: kernelovy hi-res casovac take neni pro VoIP moc uzasny, protoze "casuje" na zaklade mocnin dvojky a pak, celkem pochopitelne, nelze dosahnout presnych 20 ms...
Ad Asterisk 1.4, 1.2, SIP a IAX2: naprosto souhlasim. Lepe bych to nenapsal :-)
Ad rozklad zateze: stale trvam na tom, ze to neni resitelne - jak jsem odpovidal jinemu diskutujicimu: aby to fungovalo, musel byste zajistit spravedlive rozdelovani uzivatelu dle zateze, kterou generuji a hlavne zajistit, aby si navzajem nevolali uzivatele mezi jednotlivymi Asterisky. A oboje je IMO nerealne.
Ono se take na vse (v tomto vlakne zminene) bude jinak divat cesky operator s tisici soucasnych hovoru, a jinak nemecky s desitkami tisic soucasnych hovoru. O Vonage ani nemluve :-)
Jeste k tomu ztdummy. Granularita toho timeru je 1mikrosekunda na beznem HW a casovani 20ms ramcu je pomerne presne. Problem je spis v tom, ze ten casovac neni synchronizovan s druhou stranou, coz ale neni zadny VoIP 2 VoIP prenos, takze vlivem rozjizdeni hodin nejaka ta data casem pretecou (coz sice nikdo nepozna, ale pro data to neni).
Je pravda, ze volani si mezi sebou je velmi obtizne resitelny problem, pokud by se prihlasoval na predem neznamy asterisk :) Na centralizovane reseni IAX2 proste neni. Nicmene je dobre poukazat na fakt, ze pro interni komunikaci mezi systemy je to zajimava volba, ktera opravdu funguje.
Prave dnes nase firma presla na VoIP, takze cerstve zkusenosti. Mame cca 20 zamestnancu, doposud kombinace HTS a pobockova ustredna Panasonic. Dneska jsme presli k Broadnetu (nyni Vodafone), pouzivaji reseni na protokolu MGCP http://en.wikipedia.org/wiki/Media_Gateway_Control_Protocol. Ve finale se da +- nasimulovat funkcnost toho Panasonicu, s cimz mela vetsina Asterixovejch reseni docela problemy.
H323 je sice binarni, ale je to vlastne SS7 kodovane pomoci ASN1.1 - pro dekodovani staci mit wireshark a cloveka ktery ma zkusenosti s hlasovymi sluzbami.
Ono to z Q.931 primo vychazi. H.323 s SS7 nema imho mnoho spolecneho. Jinak tady na tech protokolech je krasne videt stret mezi TDM (telefonaky) a Ethernetovym svetem (internet)
H.323 je binarni slozity protokol, pricemz uz jenom samotna implementace kvalitniho H323 stacku je beh na dlouho. SIP je jednoduchy textovy protokol vychazejici z "internetoveho" sveta (byt ho navrhli v IEETF nebo jak se to pise). Nakonec se prosadil prave SIP kvuli jednoduchosti na implementaci.
TDM site (ISDN, SS7) jsou drahe slozite srandy (ale na druhou stranu v kazdem case garantuji stanovenou kvalitu prenosu). Nicmene "internet" uz neni co byval a se stalym zrychlovanim (predimenzovavanim) se nemusi resit na vsech prvcich QoS, coz je o rad levnejsi, nez u siti TDM. Proto se taky VoIP zacina prosazovat (ono to teda neni uplne jen tim).