forum.odorik.cz

Zdravím,
tohle vypadá že je nějaká karta do konkrétní PBX. Asi moc v tomto pípadě nepomůže, jen pokud by uživatel tyto systémy měl.
V momentě když by uživatel měl u těch modemů PBX, nabízelo by se řešení více jak to rozchodit.....u zavedených firem se začínalo s voipenm na H323 což je vlastně zabalená DSS1 do IP, a tam toho projde více, ale zase je problém s tím že to zase neumí ty nové voip ústředny.
Jasně že pro nové instalace už nikdo řešit nebude, ISDN dožije spolu s TDM ústřednami. Ale to, kdy a jestli někdy ještě vůbec se kvalitou signalizace vyrovnáme TDM době(spožděním nikdy), to je ve hvězdách. Řeším bohužel denně, kdy se v tom co operátoři dnes dokážou vracíme do 80tých let. Čest vyjímkám zde u odorika Ale ISDN/DSS1 tu s námi ještě nějaký ten pátek bude, ty PBX tak rychle nevymizí, tak jako tu stále je CAS/R2, a donedávna i 3drátová provolba
Ale zajímalo mne to právě proto že někdo isdn data chce, protože to není běžné. U mne např.čekají ISDN videotelefony na rozchození(jako ukázka v dnešní době hezké), ale už jen na vlastní infrastruktuře, přes opy bohužel

Samozřejmě, že je to jenom karta, protože využívání "ISDN over IP" se týkalo takřka výhradně korporátní sféry a ne home userů. Ti v naprosté většině případů neměli ani to ISDN jako takové, natož aby řešili jeho pozdější připojení na širokopásmový net. ISDN byla v podstatě slepá cesta, takový nepovedený krok mezi dial-up a xDSL, ovšem velmi dobré pro operátory na tahání peněz z uživatelů, kterým se účtovala cena x2 za rychlost 128 kbps (2x 64 kbps). Taky jsem si užil svoje, hlavně s příchodem OS W2k, kdy najednou euroISDN telefon DeTeWe EuroMaster Data byl k ničemu, protože jeho podpora končila u W98SE a než se výrobce probudil a ovladače dodělal, tak už přišlo xDSL a VoIP. A nebylo co řešit.

jasně, mluvím hlavně o hlasu, data byla vždy minorita, i u téhle PBX to bylo určitě o hlasu. A ještě před pár lety bylo ISDN 95procent provozu do PBX, nyní odhaduju tak 50....ústupu napomáhá to, že dobrou signalizaci i ti velcí přestávají umět.
V dnešní době graduje taky problém právě analogových modemů, které přes voip nejedou, a s faxy jsou problémy.... A nahradit je IP je někdy neřešitelné. To že tazatel dokáže na voipu takovou rychlost modemu je těžko k uvěření......mám kolikrát problém i s 9k6, a na horším internetu je spojení vyloučeno, prostě to na tak nekvalitní přenos a spoždění není stavěné A donutit někdy IT ve firmě namapovat port je někdy nemožné, ikdyž to člověk sám nahradit chce. ISDN/DSS1 tu bude ještě dlouho daleko dříve umře ss7.
Ale ať neuíkám, ty ISDN data mne zajímají a pokud tazatel více rozepíše místní podmínky, třeba to dáme Taky by mne to zajímalo jestli ty pattony to daj.

JPesak píše:ISDN data(64k unrestricted) přes voip je trochu vyšší dívčí, ale jde to.

Zaujímavé. To by ma dosť zaujímalo ako to technologicky ide.

Kvôli prijímaniu SMSiek som si písal vlastný softwarový V.23 FSK modem, ktorý má dátový tok iba 1.2kb/s a dáta moduluje do PCMA/PCMU. Rýchlosť by som možno ešte dokázal zvýšiť na dvojnásobok alebo trojnásobok. To je stále menej ako desatina z 64kb/s a podľa mňa už je to strop, čo je technologicky/matematicky ešte možné. PCMA/PCMU má naviac logaritmickú kvantizáciu, čo komplikuje rozpoznávanie vyšších frekvencií v prenášanom signále.



Späť k pôvodnému problému. V ISDN sa používa D-kanál na signalizáciu. V SIPe je signalizácia riešená čisto textovým protokolom a rozumne sa tam nedá pridať vyhradený dátový tok na custom traffic. Asi by to šlo riešiť zabaľovaním dát z D-kanálu do RTP trafficu posielaného počas early-media, teda v čase keď sa hovor ešte naväzuje. K tomu by ale bolo potrebené aby custom RTP traffic prepustila ústredňa po ceste až do cieľovej stanice. Odorik to tuším podporuje ale iba v rámci svojej siete keď sa volá priamo na číslo linky a ako prefix sa použíujú dve alebo tri hviezdičky.

V pôvodnom príspevku sa píše, že sa používa VoIP brána Patton SN-DTA/1BIS2V. Myslím si, že problém už bude priamo v nej, nevie ako má bezstrátovo previesť ISDN D-kanál na SIP. Resp. ak to vie (napr. cez vyššie popisaný custom RTP traffic), tak treba patrične nastavit ústredňu cez ktorú SIP/RTP prechádza. Treba zistiť, či takúto vec vôbec tá VOIP brána podporuje.

V minulosti Cisco na svojich VOIP bránach používalo custom RTP traffic na signalizáciu FAXového prenosu. Takže dve Cisco kompatibilné brány sa sa vedeli medzi sebou cez SIP/RTP protokol dohondúť, že chcú poslať FAX a prepli sa na svoj custom binárny protokol (namiesto použitia modemu zabaleného v PCMA/PCMU). Takže nie je to až tak nezvyčajné používať dátový RTP traffic v SIPe na custom signalizáciu.

Zdravím,
samozřejmě jediná cesta je přenášet opravdu data....nemůžou se modulovat do PCMA(u je amerika), takže to musí proběhnout tak že GW na začátku pozná právě požadavek na službu "chci ISDN data" a pošle je transparentně na druhou stranu kde zase se data stejně jak přijdou pustí, a tím se nic nedegraduje pokud internet mezi zařízeními dovolí.
A teď ten D-kanaál. Tam je problém v tom, že ta signalizace se nezabalí a nepřenese, ta se transformuje do sipu, a na druhé straně se z ní zase dělají ISDN zprávy, tzn. se dost informací ztratí dle toho, jak ty GW jsou kvalitní. Takže pokud ty modemy si v rámci sestavení spojení chteějí předat něco více sofistikovaného, můžou se rovnou na tom zkácet a spojení nevytvoří.

Ohledně FSK tomu věřím, tam ani po drátech nebylo potřeba velkou rychlost pro přenesení sms či CLIPu. A normální modem kolik dá přes klasickou dig. síť víme, o moc nad 45kbit se analogově nedostaneme. Ale v momentě když tu PCMA dáme do voipu(g711) díky spoždění a občas výpadkům jsme tak na max 9k6...ale je to logické, protože přenášíme data přes hlas, který je přenášený přes pakety... ale co s tím když Vám někam nevede nebo někdo nechce dát LAN

To že by se signalizace přenášela v "B" kanále jsem ve voipu ještě neviděl, naposledy u R2ky...ale není to třeba, pokud by se chtělo, ten SIP by to taky přenesl, ale to už nikomu moc za to nestojí dělat, protože potřeba dnes už je monimální.
Ohledně toho pattona bych čekal že to právě nějak umět bude, jsou to přece jen profi GW, a pokud se mu to povolí, dokáže minimálně jednoduchý požadavek na "transparentní data" předat na druhou stranu, a pokud to půjde přes ústřednu, ta to nesmí samozřejmě sabotovat. Ale nezkoušel jsem, protože tam kde to je potřeba přenáším transparentně E1 a PBX na obou koncích si můžou povídat plnohodnotně, ale nikam do veřejného operátora to neposílám.

Ano, tohle se dá přirovnat k T.38, což na jedné straně demoduluje ten fax, a na druhé straně vypíská.....používá se to stále, ale tím že to je "inteligence vprostřed" tak se značně zvětšuje možnost že se ty faxy nedomluví. Proto pokud je kvalitní internet, jeví se pro praxi lepší g711 a protlačit zvuk....občas to i chodí Vysvětlete normálnímu userovi že snadná náhrada za fax není Ono pro někoho víc než založit papír a naťukat číslo je problém Takže se drží i v této naprosto nelogické kombinaci kdy si 2 faxy datově povídají přes hlas přenášený v datech

Takže zpět.... pokud tazatel má celou trasu pod kontrolou, chce to mít analyzátor ISDN, a zkoušet nastavovat ty pattony......jsou to kvalitní GW, i tyhle malé BRI, věřím že s tím počítají.

Nemyslím teraz ani T.38. Cisco malo na to custom neštandardný signalizačný kanál v SIPe ešte pred tým, než prišlo T.38. T.38 je viac-menej štandardná vec v SIPe a signalizácia o dostupnosti T.38 ide klasickou SIP signalizáciou (cez INVITE pakety). Tým som chcel poukázať hlavne na to, že v SIPe ide prenášať aj custom signalizáciu (Cisco je dôkazom, že to šlo naimplementovať a trasparentne rozbehať). A keď použitá ISDN<-->SIP brána je naozaj kvalitná, tak by mohla mať tiež nejaký custom SIP spôsob ako preniesť celú signalizáciu z D-kanálu.

Ja by som odporúčal dve tieto brány pripojiť na rôzne Odorik linky a vytočiť z jednej brány hovor na tú druhú iba pomocou čísla Odorik linky prefixovanými dvomi alebo tromi hviezdičkami. Vtedy by mala Odorik ústredňa transparentne preniesť celý obsah INVITE paketu a umožniť aj custom RTP payload (čo je asi jediné miesto, kde by sa mohla signalizácia z D-kanálu zachovať) ešte pred tým, než druhá strana potvrdí finálny ACK na INVITE.

pali píše:Nemyslím teraz ani T.38. Cisco malo na to custom neštandardný signalizačný kanál v SIPe ešte pred tým, než prišlo T.38. T.38 je viac-menej štandardná vec v SIPe a signalizácia o dostupnosti T.38 ide klasickou SIP signalizáciou (cez INVITE pakety). Tým som chcel poukázať hlavne na to, že v SIPe ide prenášať aj custom signalizáciu (Cisco je dôkazom, že to šlo naimplementovať a trasparentne rozbehať). A keď použitá ISDN<-->SIP brána je naozaj kvalitná, tak by mohla mať tiež nejaký custom SIP spôsob ako preniesť celú signalizáciu z D-kanálu.

Ja by som odporúčal dve tieto brány pripojiť na rôzne Odorik linky a vytočiť z jednej brány hovor na tú druhú iba pomocou čísla Odorik linky prefixovanými dvomi alebo tromi hviezdičkami. Vtedy by mala Odorik ústredňa transparentne preniesť celý obsah INVITE paketu a umožniť aj custom RTP payload (čo je asi jediné miesto, kde by sa mohla signalizácia z D-kanálu zachovať) ešte pred tým, než druhá strana potvrdí finálny ACK na INVITE.

Pořád to bude INVITE a klasické SIPové zprávy, ale bude tam něco navíc, a musí si domluvit "kodek", podobně jako T.38.....ale zcela jistě neimplementují vše co DSS1 umí, to jsem zatím neviděl, a to nemluvě o tom pokud si zařízení usmyslí použít "user-to-user signalling". To tak možná u té H323.

Já bych šel ještě dál a napřed bych je propojil jen mezi sebou, projít jejich nastavení, povolit na IP části patřičné "kodeky" a.....pokud se domluví, nabalovat dále další mezičlánky. Pokud se tu tazatel objeví, jeden ten patton mi v síti běží, podíval bych se do něj jestli tohle není spíše jen akademická debata