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
[email protected]
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/
