[Techinfo] VOIP SIP probléma több szolgáltatónál - folyt köv.

[Sándor Fehér]

 >szerintem a kliens-kliens forgalmat nem tereled vpn-be, ez a hiba, igy 
a kovetkezo ket dolog tortenik.
Ez kizárt, a push redirect gateway opció van használatban a 
"client-to-client" mellett.
Traceroute, speedtest és szerver oldalon iptraf programokkal megerősítve.

 >szoval szerintem nezd at a klienseid IP cimeit, hogyan kapcsolodnak 
egymashoz, ellenorizd tcpdumppal, hogy milyen cimrol milyen cimre megy 
az RTP, valoban ervenyre jut-e a directmedia (vagy ezzel ekvivalens 
beallitas).  mert ertem en, hogy a beallitas ott van es ugy >kellene 
mukodnie, de lassunk bizonyitekot, hogy valoban ugy is mukodik.
Szerintem a freepbx os (gányolt centos 7) lesz a ludas. >>> nagy kalap 
xar az egész, véleményem szerint, mert semmi nem úgy működik benne, mint 
valami normális debian/ubuntu -ban.

MEGUNTAM a szórakozást:
Feltelepítettem a debian 8.8 -at és manuális telepítéssel ráraktam a 
freepbx gui-t ma délután. >>> egy kicsit pilótavizsgás a  történet :)

  Szerintem igazad volt mindvégig a router/tűzfal hibával, ugyanis a 
freepbx os gyári tűzfala enyhén szólva is xar és ezért telepítettem fel 
az egészet a debian-ra.
pl: az állapotok felismerése igencsak nem jól működik (-m state 
established/related , iptables-nél)

Debian alatt most egyelőre úgy tűnik, hogy MINDEN OK.
Köszönöm a segítséget!



2017. 08. 21. 13:09 keltezéssel, ka at mayten.sch.bme.hu írta:
> On 2017-08-19 16:51, Sándor Fehér wrote:
>>> Amit legutobb lattam, abban konkretan directmedia volt a beallitas neve
>> A freepbx os-t használom, asterisk 13. verzióval ( latest v.13.17.0)
>> A freepbx nem teszt különbséget a reinvite és directmedia lehetőség
>> között, a kettő ugyanaz.
>> Az exten-ek nél és a gyökérben, a sip.conf -ban is globálisan tiltva
>> van a "reinvite/directmedia" ezt most le is ellenőriztem újra.
>>
>
> vegigolvastam megint.  ertem, hogy a beallitas megvan, a tcpdump is 
> ezt mutatja?
>
>>> Amugy az eredeti problema mi volt?
>> Van két sp3102 : A és B
>> "A" hívó ( sip/11 "caller") és "B" hívott ( sip/12 "callee")
>> Ha "A" hívja "B" -t a kapcsolat kiépül, csörög "B". A hívás fogadás is
>> sikerül és "A" hangja hallható "B" -nél, de "B" nem tud beszélni "A"
>> val. :) 10 másodprec elteltével, pedig a hívás megszűnik magától.
>
> nem derult ki, hogy ezek egy halozatban vannak-e.  a multkori 
> leveledben frankon lerajzoltad ascii-ban a telefonkozpont fele meno 
> utat, de igazabol nem azzal van gondod, hanem a kliensek fele meno 
> forgalommal - azt viszont nem rajzoltad le.
>
>> tcpdump: a hívás kiépül rendesen, majd vpn-en KÍVÜL mennek/mennének az
>> rtp csomagok ( udp 10.000 és udp 20.000 között). Ha kikapcsolom a
>
> felteszem ez a direkt forgalom a kliensek kozott.  az, ami az elso 
> bekezes szerint ki van kapcsolva, tehat ennek a szerver ip cimere 
> kellene, hogy menjenek.
>
> de ha arra mennenek, akkor nem tudnanak a vpn-en kivul menni, hiszen 
> ez L4 forgalom, a vpn pedig L3-ban van.
>
>
>> tűzfalat, akkor jó a hívás mindkét irányban és nem szakad le a hívás,
>> de NEM vpn-ben zajlik a kommunikáció( rtp csomagok)
>
> ez normalis mukodes, pontosabban mindket fele a mondatnak normalis 
> mukodes egy hibas beallitas eseten.
>
> szerintem a kliens-kliens forgalmat nem tereled vpn-be, ez a hiba, igy 
> a kovetkezo ket dolog tortenik.
>
> 1) a tuzfal meg ha tudna is intelligens lenni, es 'related' 
> forgalomnak felismerne az RTP streamet, nem tudja, mert titkositottan 
> megy a hivasfelepites, igy nincs mihez tarsitani az RTP-t.  vagy ez, 
> vagy primitiv a tuzfal es nem tudja akkor sem a kettot osszerendelni, 
> ha a hivasfelepitest meg latna is.
>
> 2) mivel az RTP stream egyiranyu, az egyik fel megunja a timeout utan 
> es lebontja a kapcsolatot szabalyos SIP uzenetetkkel.  ebben semmi 
> rendkivuli nincs, ez kovetkezmeny, nem ok.  es nyilvan, ha a tuzfal 
> nincs a kepben, megy a titkositatlan RTP stream, hiszen routing 
> problemad van, nem vpn es nem tuzfal.
>
>> A vpn "routed"-ként van konfigurálva és NEM "bridge" ként.
>>
> ez mind rendben, de csak a kliens-szerver kapcsolatra fokuszalsz, a 
> beszelgetes pedig kliens-kliens a leirasod alapjan
>
>> Az új vlan segítségével egy új hálózati interfészt hoznák létre, ami
> hoznek, de mindegy.  szoval szerintem egy eleg egyszeru vpn 
> konfiguralasi / routing hibad van, kar lenne ezt tovabb bonyolitani.
>
> szoval szerintem nezd at a klienseid IP cimeit, hogyan kapcsolodnak 
> egymashoz, ellenorizd tcpdumppal, hogy milyen cimrol milyen cimre megy 
> az RTP, valoban ervenyre jut-e a directmedia (vagy ezzel ekvivalens 
> beallitas).  mert ertem en, hogy a beallitas ott van es ugy kellene 
> mukodnie, de lassunk bizonyitekot, hogy valoban ugy is mukodik.
>
> ha valoban csak vpn es routing hiba, aug 31-en (varhatoan nem modosul 
> a datum) a kovetkezo eloadasban pont ilyesmiket fogok reszletezni.
>
> udv
> adam
>
>
> _______________________________________________
> Techinfo mailing list
> Techinfo at lista.sulinet.hu
> Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo
> Illemtan: http://www.szag.hu/illemtan.html
> Ügyfélszolgálat FAQ: http://sulinet.niif.hu/