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

[ka at mayten.sch.bme.hu]

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