forum.odorik.cz

Děkuji. Musím vás prvně pochválit za dobře nahlášené podivné chování. Čím více konkrétních věcí a čím více napíšete tím nám to lépe pomůže. Bod 2 by mohl být způsoben tím, že vyšší verze asterisku z ničeho nic začala posílat navíc sip signalizaci, která se má za úkol přesvědčovat že hovor žije. No a pokud na to nikdo neodpoví hovor zavěsí s tím že je něco špatně a to i když rtp tok bez problémů proudí dále.
To že SIP signalizace nemá v sobě zabudovanej mechanismus, který by umožňoval kontrolovat, zda hovor stále žije je to zásadní chyba při návrhu sip protokolu. Nyní se to různí bastlíři různě dodatečně snaží ošetřovat tak, aby neporušili normu která na takto zásadní věc zapomněla myslet na samém začátku. A snaží se to udělat tak, aby většina stávajících zařízení fungovala. Tedy myslím že sip zařízení si posílají nějaké nesmyslné sip zprávy v různých někdy náhodných intervalech, čímž se přesvědčují, že druhá strana žije.
V každém případě je nejjistější sledovat život hovoru pomocí rtp proudu což bylo ještě před pár lety jediný běžný způsob. To ale degraduje základní myšlenky sip protokolu. Základní myšlenka sip protokolu je, že rtp může jít jinou cestou a nezávisle na signalizaci.

Možná by to mohl být stejný problém i u voipbuster, kdy jejich "bastlíř" tento interval nastavil na neobvykle krátkých 15 vteřin od začátku hovoru. Možná právě proto, že není schopen kontrolovat rtp.


Už jsme to jednou řešili, možná to opět přestalo fungovat. V pondělí se na to podíváme.

update
Co se týče bodu 3. Přerušené příchozí hovory, jedná se o běžné příchozí hovory na geografická čísla ? Vypadá to že ano. Třikrát došlo k přerušení přesně po 32 vteřinách, což vypadá podezřele. Před několika dny jsme řešili takto přerušování odchozích hovorů a tam se ukázalo, že příčina byl příliš rychlý NAT, který uzavřel spojení už po deseti vteřinách. A telefon tak neodpověděl na hlášku "zdvihnuto", což mělo za následek zavěšení hovoru po 32 vteřinách. Tohle ale tento případ být nemůže, protože šlo o příchozí hovory, ale mechanizmus by mohl být podobný. V připravované nové proxy budeme logovat veškerou sip signaliziaci týden zpět, takže záhadné problémy co se vyskytnou jen občas tohoto typu se pak budou řešit mnohem snadněji. Hovory na sipa a uri budou logovány jen částečně, ale tam moc variant co může být špatně zase není.

xsouku04 píše:Musím vás prvně pochválit za dobře nahlášené podivné chování. Čím více konkrétních věcí a čím více napíšete tím nám to lépe pomůže.

Díky za poklonu. Inu, berte to tak, že je to něco jako profesionální deformace :)

K bodu 1. svoji myšlenku podsouvat stále nebudu, ale k bodu 3. bych na základě "update" ještě dodal, že dané místo má pevnou IP adresu, ovšem nějaký překlad tam cestou je - v ifconfig je 10.51.13.30, ovšem navenek se to jeví jako 94.142. atd. Jde o připojení v síti Petriny.net, což je poskytovatel jehož lidé - podle mé zkušenosti - dobře rozumí své práci a jsou vstřícní; myslím, že by se nezdráhali komunikovat o tom, jak to dělají. (Podle té vnitřní IP velmi dobře zjistí, co/kdo to je.)

Zapomněl jsem ještě na jednu věc, související s problémem č. 3. Při přerušení hovoru SJphone vždy nahlásil příčinu: ACK Timeout.
(Omlouvám se. To jsem tam samozřejmě měl napsat už napoprvé. Prostě jsem to přehlédl, jak jsem toho psal víc :) )

Zdravím. Bod 2. byl opraven. Problém by v tom, že Mikrotech po jisté době pošle reinvite, aby se přesvědčil že hovor žije. (prakticky sledování RTP bohatě stačí - RTP přes něj jde celkem určitě se též sleduje) to když jsme přeposlali telefonu, tak ten na to již na reinvite neodpověděl, takže mikrotech nikdy nedostal odpověď. Nyní tedy na každé reinvite odpoví naše proxi zprávou OK, čímž tuto zbytečnou kotrolovu navíc vypíná. Hovory se nyní nepřerušují.
Jako důsledek ale nebude fungovat faxování na SIPA, pokud rovnou od začátku není použit kodek ALAW. Protože na případné reinvite - změna kodeku během hovoru, také odpovíme falešné OK. Faxové hovory jsou ale krátké a nastavením ALAW kodeku lze potížím vyhnout, takže pochybuji, že by to někomu vadilo.

Co se týče přerušování volání na URI. Nemohl by jste nám poskytnout nějaké uri ne které bychom mohli udělat jeden či dva testovací hovory ? Myslím že situace bude obdobná. Náš asterisk na 4smart, ono podivné reinvite neposílá.

xsouku04 píše: Nemohl by jste nám poskytnout nějaké uri ne které bychom mohli udělat jeden či dva testovací hovory ? Myslím že situace bude obdobná. Náš asterisk na 4smart, ono podivné reinvite neposílá.

Zkuste linku 5107 - ing. Židů (URI vytvoříte známým způsobem, TUL je 42048535xxxx, xxxx je linka). Právě jsem s ní mluvil a nebude jí to vadit.
Ke všem jiným záležitostem se vyjádřím večer nebo zítra, omlouvám se, ale teď nestíhám :(

Mně tohle samé dělá právě moje Cisco 7905. Problém jsem vám již hlásil ? Bude se s tím něco tedy dít ? Všude jinde telefon funguje.

Bylo mi slíbeno, že mi prozradíte IP nové ústředny, abych si to mohl odzkoušet. Psal jsem i mail, ale zatím žádná odpověď.

Díky

Zkuste linku 5107 - ing. Židů (URI vytvoříte známým způsobem, TUL je 42048535xxxx, xxxx je linka). Právě jsem s ní mluvil a nebude jí to vadit.

Takže bod 1 byl též opraven. Tamní cisco bylo zmatené z naší to hlavičky až z toho po jisté době "zapomnělo" posílat rtp. Zvláštní je, že přijímat rtp nezamnělo.

Zdravím,
k bodu 1.:
Potvrzuji, že to již funguje – vyzkoušeno. (Jediné, co by mne tedy ještě v souvislosti volání na URI do TUL zajímalo, je to, proč se obecně nejde dovolat na jejich ústřednu, jak jsem už tady psal ve vláknu k tomu příslušném. /Samozřejmě, že to není vina Odoriku./)
k bodu 2.:
Opět potvrzuji – funguje, vyzkoušeno.
k bodu 3.:
Podařilo se mi zreprodukovat tutéž situaci, při které se hovor před x dny rozpadl – stejné místo připojení, stejná hw i sw konfigurace, stejná linka VTS ze které se volalo (call id 39342810). Problém nenastal. Dělali jste s tím něco, nebo je to třeba připsat do listiny „již se neobjevující potíže neznámého původu“? :)
Celkově:
Díky za kvalitně odvedenou profesionální práci.

add 3. žádné změny jsme neprováděli.

xsouku04 píše:add 3. žádné změny jsme neprováděli.

:) Inu, za sebe to tedy nechávám být - a uvidím, co bude dál. Pokud vám tahle kauza (resp. informace z ní) bude užitečná někdy v budoucnu, je to jen dobře.