Re: [Techinfo] VOIP SIP probléma több szolgáltatónál - folyt köv.
Sziasztok! 3CX voip rendszert használ valaki? Kipróbáltam az asterisk helyett és volna 1-2 kérdésem ahhoz, aki használja a 3CX -et. Üdv! Jó Hétvégéét Mindenkinet! 2017. 08. 22. 16:51 keltezéssel, k...@mayten.sch.bme.hu írta: On 2017-08-22 15:21, Zoltan Nyiro wrote: módon a vonal 3-5 perc telefonálás után megszakad. Router egy tcpdump szerint ki kuldi a sip bye uzenetet? logok szerint ki timeoutol el? cisco (linksys) RV042 vpn router. Azért ez a router van mert van egy másik telephely ahol van szintén egy RV042 és a 2 telephely a vpn egy szabvany (vagy inkabb tobb), nem csak ugyanazon modellekkel mukodik. Telekom azt mondja biztos a helyi hálóban van a hiba. Most addig ha nekik is csak annyi informaciot adtal meg, mint ide, akkor szerintem is a hely haloban van a hiba. udv adam ___ Techinfo mailing list Techinfo@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/ ___ Techinfo mailing list Techinfo@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/
Re: [Techinfo] VOIP SIP probléma több szolgáltatónál - folyt köv.
On 2017-08-22 15:21, Zoltan Nyiro wrote: módon a vonal 3-5 perc telefonálás után megszakad. Router egy tcpdump szerint ki kuldi a sip bye uzenetet? logok szerint ki timeoutol el? cisco (linksys) RV042 vpn router. Azért ez a router van mert van egy másik telephely ahol van szintén egy RV042 és a 2 telephely a vpn egy szabvany (vagy inkabb tobb), nem csak ugyanazon modellekkel mukodik. Telekom azt mondja biztos a helyi hálóban van a hiba. Most addig ha nekik is csak annyi informaciot adtal meg, mint ide, akkor szerintem is a hely haloban van a hiba. udv adam ___ Techinfo mailing list Techinfo@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/
Re: [Techinfo] VOIP SIP probléma több szolgáltatónál - folyt köv.
Helló! Bocs, hogy ide beírok, de az én problémám is kapcsolódik ide. Telekom telepített pár cisco ip phone 303 készüléket és érdekes módon a vonal 3-5 perc telefonálás után megszakad. Router egy cisco (linksys) RV042 vpn router. Azért ez a router van mert van egy másik telephely ahol van szintén egy RV042 és a 2 telephely között vpn kapcsolat van. Valaki találkozott ilyen hibával? Telekom azt mondja biztos a helyi hálóban van a hiba. Most addig eljutottam, hogy az egyik routert kicseréltem egy mezei tp-linkre amivel nem produkálja a hibát. Nem hinném, hogy egy ilyen egyszerű routerrel megy másikkal meg nem? Köszi Zoli 2017. augusztus 21. 22:17 Sándor Fehér írta, < fehersan...@madach-starjan.sulinet.hu>: > >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, k...@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
Re: [Techinfo] VOIP SIP probléma több szolgáltatónál - folyt köv.
>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, k...@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@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/
Re: [Techinfo] VOIP SIP probléma több szolgáltatónál - folyt köv.
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@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/
Re: [Techinfo] VOIP SIP probléma több szolgáltatónál - folyt köv.
>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. >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. 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 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) Egyedül az udp 5060 sip port kapcsolat kiépülése megy a vpn-ben és ez így nem az igazi. >amiben a gw es a szerver kozott van az openvpn-ed, aminek gondolom van egy ip tartomanya is, akkor gondolom az asterisknek celszeru volna bindelnie a privat ip cimre a szerveren is, Ez így van és az asterisk is BIND-el a 192.168.254.254/24 címen. ( ez a vpn tartomány) A kliensek is ide erre a címre csatlakoznak. A vpn "routed"-ként van konfigurálva és NEM "bridge" ként. >nem teljesen vagom, mi koze van egy uj vlannak ehhez, Az új vlan segítségével egy új hálózati interfészt hoznák létre, ami sehova nem csatlakozik és ide bridgelném a vpn klienseket. Nem szeretem az ifconfig eth0:1 . stb alinterface machinálgatásokat :D Kérdés, hogy kérjek új hálózati interfészt, ami nem csatlakozik a netre és oda bridgeljem a vpn klienseket? Esetleg mit hagytam ki és mit érdemes még megnéznem? 2017. 08. 18. 17:30 keltezéssel, k...@mayten.sch.bme.hu írta: On 2017-08-18 15:37, Sándor Fehér wrote: A sip beállításoknál a " reinvite" lehetőség "no" -ra van téve. Én úgy tudom, hogy ez kell ahhoz, hogy a kliensek a en is igy tudom. nem tudjuk (vagy nem emlekszem), hogy milyen verzioju asterisk van nalad, de konkretan ez az opcio az evek soran valtozott. En sem kovettem, hogy most eppen mi, de a sip.conf -ban egyertelmu peldakat fogsz talalni. Amit legutobb lattam, abban konkretan directmedia volt a beallitas neve, igy a legegyszerubb a peer-eket az orokolheto profilokkal konfiguralni, a gyoker profilban pedig szerepelhet egy directmedia=no beallitas. De ez fugg nyilvan attol, milyen verzioju asterisked van. Amugy az eredeti problema mi volt? Van egy olyan erzesem, hogy amugy semmi koze a vpn-hez, de lehet rosszul emlekszem. Szoval ha egy ilyen sima felallasod van: [lan]--[gw]--internet--[szerver] amiben a gw es a szerver kozott van az openvpn-ed, aminek gondolom van egy ip tartomanya is, akkor gondolom az asterisknek celszeru volna bindelnie a privat ip cimre a szerveren is, azert, hogy a gw mogotti kliensek a privat cimen erhessek el. ugye ez tortenik most is es ennek ellenere nem mukodik valami? Jó megoldás lehet egy vlan-t létrehozni és oda bridgelni vpn-en a klienseket? nem teljesen vagom, mi koze van egy uj vlannak ehhez, es hogy mit szeretnel bridge-elni, azt plane, hogy ebbe hogy jon bele a vpn. udv adam ___ Techinfo mailing list Techinfo@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/ ___ Techinfo mailing list Techinfo@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/
Re: [Techinfo] VOIP SIP probléma több szolgáltatónál - folyt köv.
On 2017-08-18 15:37, Sándor Fehér wrote: A sip beállításoknál a " reinvite" lehetőség "no" -ra van téve. Én úgy tudom, hogy ez kell ahhoz, hogy a kliensek a en is igy tudom. nem tudjuk (vagy nem emlekszem), hogy milyen verzioju asterisk van nalad, de konkretan ez az opcio az evek soran valtozott. En sem kovettem, hogy most eppen mi, de a sip.conf -ban egyertelmu peldakat fogsz talalni. Amit legutobb lattam, abban konkretan directmedia volt a beallitas neve, igy a legegyszerubb a peer-eket az orokolheto profilokkal konfiguralni, a gyoker profilban pedig szerepelhet egy directmedia=no beallitas. De ez fugg nyilvan attol, milyen verzioju asterisked van. Amugy az eredeti problema mi volt? Van egy olyan erzesem, hogy amugy semmi koze a vpn-hez, de lehet rosszul emlekszem. Szoval ha egy ilyen sima felallasod van: [lan]--[gw]--internet--[szerver] amiben a gw es a szerver kozott van az openvpn-ed, aminek gondolom van egy ip tartomanya is, akkor gondolom az asterisknek celszeru volna bindelnie a privat ip cimre a szerveren is, azert, hogy a gw mogotti kliensek a privat cimen erhessek el. ugye ez tortenik most is es ennek ellenere nem mukodik valami? Jó megoldás lehet egy vlan-t létrehozni és oda bridgelni vpn-en a klienseket? nem teljesen vagom, mi koze van egy uj vlannak ehhez, es hogy mit szeretnel bridge-elni, azt plane, hogy ebbe hogy jon bele a vpn. udv adam ___ Techinfo mailing list Techinfo@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/
Re: [Techinfo] VOIP SIP probléma több szolgáltatónál - folyt köv.
Üdv Adam! >mitol jobb ez, mint ipsec, vagy openvpn - mindkettot nativan tudja szamtalan OS. Gondoltam én is IPSEC-re, de: - kliens oldalon dinamikus ip van ( és ez nehezíti / scriptelni kell mikrotik esetében) - kevésbé ismerem, mint az openvpn-t A sip beállításoknál a " reinvite" lehetőség "no" -ra van téve. Én úgy tudom, hogy ez kell ahhoz, hogy a kliensek a központon keresztül kommunikáljanak és ne egymással. Többek közt, ha ez yes-en van, akkor pl nem működik a hívásrögzítés sem a mixmonitorral. Kérlek javíts ki ha tévednék. Ezen beállítások ellenére sem működött a vpn-el a rendszer. Írtad, hogy nem láttál ip címet stb, így a topologia a következőképpen néz ki: LAN ( 192.168.10.0/24) Mikrotik (diginet, 94.21.x.x vagy 217.x.x.x publikus és dinamikus ip) >>> VPS ( szerverplex, proxmox alapú kvm rendszer, 76.x.x.x publikus FIX ip és csak ez az egy "kártya" van benne) A telefon adapterek: SPA3102 cisco/linksys ( sajnos nem tudnak natív srtp-t ) Egyéb kliensek: android + win (laptop) zoiper alkalmazással ( natívan tudja az srtp-t, itt nem létkérdés a vpn) Az egyéb kliensek mindenféle más hálózatból is csatlakoznak NAT mögül.( pl mobilnet stb) A telefon adapterek default-gw je a mikrotik. Jelenleg titkosítás nélküli üzemmódban tökéletesen üzemelnek. Jó megoldás lehet egy vlan-t létrehozni és oda bridgelni vpn-en a klienseket? Esetleg kérjek másik " kártyát" is, ami nem csatlakozik a netre és oda bridgelni a klienseket? 2017. 08. 14. 15:10 keltezéssel, k...@mayten.sch.bme.hu írta: On 2017-08-14 14:04, Horváth Péter wrote: Vagy pl ha fut egy linux, azon lehetne virtualbox, ami már alkalmas mikrotik futtatásra. És mivel a virtualbox létrehoz belső iterface-t is ezért már lenne több interface a host OS számára. na de ennek mi ertelme? mitol jobb ez, mint ipsec, vagy openvpn - mindkettot nativan tudja szamtalan OS. Miert vezettetnel be egy plusz reteget, kulonosen, ha ez mar egy virtualis kornyezetben futtatott virtualis kornyezet lenne - ennek megfelelo teljesitmennyel (azaz kb ertekelhetetlenul lassu). udv adam ___ Techinfo mailing list Techinfo@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/ ___ Techinfo mailing list Techinfo@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/
Re: [Techinfo] VOIP SIP probléma több szolgáltatónál - folyt köv.
On 2017-08-14 14:04, Horváth Péter wrote: Vagy pl ha fut egy linux, azon lehetne virtualbox, ami már alkalmas mikrotik futtatásra. És mivel a virtualbox létrehoz belső iterface-t is ezért már lenne több interface a host OS számára. na de ennek mi ertelme? mitol jobb ez, mint ipsec, vagy openvpn - mindkettot nativan tudja szamtalan OS. Miert vezettetnel be egy plusz reteget, kulonosen, ha ez mar egy virtualis kornyezetben futtatott virtualis kornyezet lenne - ennek megfelelo teljesitmennyel (azaz kb ertekelhetetlenul lassu). udv adam ___ Techinfo mailing list Techinfo@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/
Re: [Techinfo] VOIP SIP probléma több szolgáltatónál - folyt köv.
2017. 08. 14. 9:56 keltezéssel, Sándor Fehér írta: >Openvpn az nem egy L2 bridge szintű kommunikáció Alapestben valóban ez a helyzet, de tudja az L2 bridget is. > EOIP tunnelt is kellene csinálni. A vps-nél nincs mikrotikem, sajnos így ez kiesett. hypervisort nem lehet a VPS -en futtatni? Az lenne az igazi poén :) Vagy pl ha fut egy linux, azon lehetne virtualbox, ami már alkalmas mikrotik futtatásra. És mivel a virtualbox létrehoz belső iterface-t is ezért már lenne több interface a host OS számára. >De mi lenne ha a helyi hálózat (amiben az ATA-k vannak) lenne a VPN szerver oldal, és a VPN kliens pedig a VPS-ben működő dolog. Jelenleg így van a rendszer kialakítva. A mikrotiken van egy vpn szerver és a vps pedig kliensként csatlakozik hozzá. Úgy gondolom, hogy a problémát az okozza, hogy a vps-ben csak egy hálózati interfész van és nincs mögötte tényleges belső hálózat. ( a linux netfilter így nem a forward láncon kezeli a forgalmat véleményem szerint) Én is gondoltam az L2 bridge kialakításra, de a fentiek miatt nem működne. Megkérdezem a supportot, hogy tudnak e egy plusz interfészt adni, ami nem csatlakozik a netre. Esetleg virtuális interfészt is megpróbálom, hátha. Köszönöm az ötleted, nekem is szimpatikusabb, ha nem kell 2 voip szerver. 2017. 08. 14. 9:37 keltezéssel, Horváth Péter írta: A helyes működés érdekében az lenne a legjobb ha a SIP proxy (vagyis PBX) egy broadcsat domainben lenne (L2 bridge) az ATA egységekkel mint korábban. Majd kijavítanak ha tévedek, vagy pongyolán fogalmazok, de szerintem az Openvpn az nem egy L2 bridge szintű kommunikáció, hanem egy magasabb szintű IP réteg beli. Vagyis a szerver oldali hálózat és a kliens oldali hálózat soha nem lesz egy broadcast domain openvpn-el összekapcsolva. Így ha mindenképpen openvpn-t szeretnél, akkor még az openvpn csatornán belül, egy EOIP tunnelt is kellene csinálni. Mikrotik környezetben ez lenne a legegyszerűbb. Ezen kívül ha jól értelezem, akkor jelenleg az összes ATA egység külön VPN kapcsolatot épít fel a PBX szerver felé. Viszont a VPN szervernek minden egyes felépült VPN kapcsolathoz, módosítania kell a saját routing tábláját. Ez más OS-eknél nem annyira automatizált folyamat, mint a mikrotik esetében. De mi lenne ha a helyi hálózat (amiben az ATA-k vannak) lenne a VPN szerver oldal, és a VPN kliens pedig a VPS-ben működő dolog. Vagyis az egyszerűség, és megbízhatóság érdekében ha csak 1 VPN kapcsolat lenne a helyi hálózat, és a virtuális szerver között az jó lenne. 2017. 08. 12. 23:29 keltezéssel, Sándor Fehér írta: Sziasztok! Még mindig ezzel szórakozok :) és elakadtam az "erdőben". Jelenleg a rendszer felépítése: VPS (egy adatközpontban, freepbx legújabb stable OS-al)>INTERNET >> pár darab okostelefon (zoiper titkosítva srtp-vel) I>>> MIKROTIK (OPENVPN) >> pár darab SPA3102 ata (titkosítás nélkül) A szerver eddig ott volt, ahol az ata-k és nem volt gond, hogy titkosítás nélkül mentek. Átköltöztettem a rendszert egy VPS-re és minden flottul megy, kivéve egy dolgot: A spa3102-k egy mikrotiken keresztül kapcsolódnak a vps-hez openvpn segítségével és azt vettem észre, hogy az RTP kommunikáció nem a vpn-ben történik, hanem csak a kontrol csatorna megy ott. Ha hívok egy külső telefonszámot, a kapcsolat felépülése a vpn-ben látható ( udp 5060) majd amikor a hívott fél felveszi a telefont, akkor a WAN oldalon látni az udp kommunikációt udp 1 és udp 2 között titkosítatlanul. Ez így nem túl biztonságos, mert lehallgathatóak a beszélgetések az ata-k között. Azt találtam ki, hogy csinálok még egy freepbx szervert az ata-k nak és a két freepbx-et kötöm össze titkosított IAX2-vel a SIP helyett. Működőképes az elgondolás? IAX2 tud teljes egészében a tunnelben működni? A kimenő hívások "lehallgatása" nem érdekel, de a belső telefonok, amik egymással beszélgetnek, az mindeképp titkos kell legyen! ui: Az okostelefonok a zoiperrel tudnak srtp-t/ztrp-t is és azokkal nincs ilyen gond. 2017. 06. 13. 13:44 keltezéssel, Fehér Sándor írta: Használ valaki reengert közülünk? ( VOIP, nordtelekom) Működik valakinek? Már minden jó, csak ez a szolgáltató nem megy! 2017. 06. 02. 9:37 keltezéssel, Fehér Sándor írta: Sziasztok! Ti nem találkoztatok a tárgyban említett jelenséggel? Tegnap óta egyik voip provideren sem tudok telefonálni. A jelenség annyi, hogy a hang nem megy át. Olyan mintha az RTP adatfolyam blokkolva lenne!! Több internetszolgáltatónál ezt tapasztalom. Ötlet vagy vélemény? Más is kínlódik ezzel? Üdvözlettel! ___ Techinfo mailing list Techinfo@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/ ___ Techinfo mailing list Techinfo@lista.sulinet.hu Fel- és leiratkozás:
Re: [Techinfo] VOIP SIP probléma több szolgáltatónál - folyt köv.
On 2017-08-14 08:37, Horváth Péter wrote: A helyes működés érdekében az lenne a legjobb ha a SIP proxy (vagyis PBX) egy broadcsat domainben lenne (L2 bridge) az ATA egységekkel mint korábban. erre nincs szukseg Majd kijavítanak ha tévedek, vagy pongyolán fogalmazok, de szerintem az Openvpn az nem egy L2 bridge szintű kommunikáció, hanem egy magasabb szintű IP réteg beli. Vagyis a szerver oldali hálózat az openvpn konkretan lehet l2 es l3 reteg-beli is, konfiguracio fuggo. Mukodik az l2 bar nem javasolt a hasznalata mert kontraproduktiv. Viszont a VPN szervernek minden egyes felépült VPN kapcsolathoz, módosítania kell a saját routing tábláját. Ez más OS-eknél nem annyira automatizált folyamat, mint a mikrotik esetében. ez sokkal automatizaltabb, mint gondolnad. az openvpn mondjuk egy oszvermegoldast hasznal scriptek formajaban, de peldaul az ipsec minden tamogatott platformon (a windowst is beleertve) tok automatikusan kezeli ezt. A spa3102-k egy mikrotiken keresztül kapcsolódnak a vps-hez openvpn segítségével és azt vettem észre, hogy az RTP kommunikáció nem a vpn-ben történik, hanem csak a kontrol csatorna megy ott. teljesen hetkoznapi a problema, tipikusan NAT eseten szokott elofordulni, de tudni kell a megfelelo sip beallitasokat is, nevezetesen, hogy a peerek kenyszeritve vannak-e az RTP felepitese kapcsan barmire. celszeru voltan a pbx-en at kezelni az rtp-t es tiltani a kozvetlen kapcsolatot, legalabbis elso lepesben. Mivel azonban nem derultek ki konkret ip cimek, sip fejlecek illetve beallitasok, en eddig olvastam. udv adam ___ Techinfo mailing list Techinfo@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/
Re: [Techinfo] VOIP SIP probléma több szolgáltatónál - folyt köv.
>Openvpn az nem egy L2 bridge szintű kommunikáció Alapestben valóban ez a helyzet, de tudja az L2 bridget is. > EOIP tunnelt is kellene csinálni. A vps-nél nincs mikrotikem, sajnos így ez kiesett. >De mi lenne ha a helyi hálózat (amiben az ATA-k vannak) lenne a VPN szerver oldal, és a VPN kliens pedig a VPS-ben működő dolog. Jelenleg így van a rendszer kialakítva. A mikrotiken van egy vpn szerver és a vps pedig kliensként csatlakozik hozzá. Úgy gondolom, hogy a problémát az okozza, hogy a vps-ben csak egy hálózati interfész van és nincs mögötte tényleges belső hálózat. ( a linux netfilter így nem a forward láncon kezeli a forgalmat véleményem szerint) Én is gondoltam az L2 bridge kialakításra, de a fentiek miatt nem működne. Megkérdezem a supportot, hogy tudnak e egy plusz interfészt adni, ami nem csatlakozik a netre. Esetleg virtuális interfészt is megpróbálom, hátha. Köszönöm az ötleted, nekem is szimpatikusabb, ha nem kell 2 voip szerver. 2017. 08. 14. 9:37 keltezéssel, Horváth Péter írta: A helyes működés érdekében az lenne a legjobb ha a SIP proxy (vagyis PBX) egy broadcsat domainben lenne (L2 bridge) az ATA egységekkel mint korábban. Majd kijavítanak ha tévedek, vagy pongyolán fogalmazok, de szerintem az Openvpn az nem egy L2 bridge szintű kommunikáció, hanem egy magasabb szintű IP réteg beli. Vagyis a szerver oldali hálózat és a kliens oldali hálózat soha nem lesz egy broadcast domain openvpn-el összekapcsolva. Így ha mindenképpen openvpn-t szeretnél, akkor még az openvpn csatornán belül, egy EOIP tunnelt is kellene csinálni. Mikrotik környezetben ez lenne a legegyszerűbb. Ezen kívül ha jól értelezem, akkor jelenleg az összes ATA egység külön VPN kapcsolatot épít fel a PBX szerver felé. Viszont a VPN szervernek minden egyes felépült VPN kapcsolathoz, módosítania kell a saját routing tábláját. Ez más OS-eknél nem annyira automatizált folyamat, mint a mikrotik esetében. De mi lenne ha a helyi hálózat (amiben az ATA-k vannak) lenne a VPN szerver oldal, és a VPN kliens pedig a VPS-ben működő dolog. Vagyis az egyszerűség, és megbízhatóság érdekében ha csak 1 VPN kapcsolat lenne a helyi hálózat, és a virtuális szerver között az jó lenne. 2017. 08. 12. 23:29 keltezéssel, Sándor Fehér írta: Sziasztok! Még mindig ezzel szórakozok :) és elakadtam az "erdőben". Jelenleg a rendszer felépítése: VPS (egy adatközpontban, freepbx legújabb stable OS-al)>INTERNET >> pár darab okostelefon (zoiper titkosítva srtp-vel) I>>> MIKROTIK (OPENVPN) >> pár darab SPA3102 ata (titkosítás nélkül) A szerver eddig ott volt, ahol az ata-k és nem volt gond, hogy titkosítás nélkül mentek. Átköltöztettem a rendszert egy VPS-re és minden flottul megy, kivéve egy dolgot: A spa3102-k egy mikrotiken keresztül kapcsolódnak a vps-hez openvpn segítségével és azt vettem észre, hogy az RTP kommunikáció nem a vpn-ben történik, hanem csak a kontrol csatorna megy ott. Ha hívok egy külső telefonszámot, a kapcsolat felépülése a vpn-ben látható ( udp 5060) majd amikor a hívott fél felveszi a telefont, akkor a WAN oldalon látni az udp kommunikációt udp 1 és udp 2 között titkosítatlanul. Ez így nem túl biztonságos, mert lehallgathatóak a beszélgetések az ata-k között. Azt találtam ki, hogy csinálok még egy freepbx szervert az ata-k nak és a két freepbx-et kötöm össze titkosított IAX2-vel a SIP helyett. Működőképes az elgondolás? IAX2 tud teljes egészében a tunnelben működni? A kimenő hívások "lehallgatása" nem érdekel, de a belső telefonok, amik egymással beszélgetnek, az mindeképp titkos kell legyen! ui: Az okostelefonok a zoiperrel tudnak srtp-t/ztrp-t is és azokkal nincs ilyen gond. 2017. 06. 13. 13:44 keltezéssel, Fehér Sándor írta: Használ valaki reengert közülünk? ( VOIP, nordtelekom) Működik valakinek? Már minden jó, csak ez a szolgáltató nem megy! 2017. 06. 02. 9:37 keltezéssel, Fehér Sándor írta: Sziasztok! Ti nem találkoztatok a tárgyban említett jelenséggel? Tegnap óta egyik voip provideren sem tudok telefonálni. A jelenség annyi, hogy a hang nem megy át. Olyan mintha az RTP adatfolyam blokkolva lenne!! Több internetszolgáltatónál ezt tapasztalom. Ötlet vagy vélemény? Más is kínlódik ezzel? Üdvözlettel! ___ Techinfo mailing list Techinfo@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/ ___ Techinfo mailing list Techinfo@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/ ___ Techinfo mailing list Techinfo@lista.sulinet.hu Fel- és leiratkozás:http://lista.sulinet.hu/mailman/listinfo/techinfo Illemtan:http://www.szag.hu/illemtan.html
Re: [Techinfo] VOIP SIP probléma több szolgáltatónál - folyt köv.
A helyes működés érdekében az lenne a legjobb ha a SIP proxy (vagyis PBX) egy broadcsat domainben lenne (L2 bridge) az ATA egységekkel mint korábban. Majd kijavítanak ha tévedek, vagy pongyolán fogalmazok, de szerintem az Openvpn az nem egy L2 bridge szintű kommunikáció, hanem egy magasabb szintű IP réteg beli. Vagyis a szerver oldali hálózat és a kliens oldali hálózat soha nem lesz egy broadcast domain openvpn-el összekapcsolva. Így ha mindenképpen openvpn-t szeretnél, akkor még az openvpn csatornán belül, egy EOIP tunnelt is kellene csinálni. Mikrotik környezetben ez lenne a legegyszerűbb. Ezen kívül ha jól értelezem, akkor jelenleg az összes ATA egység külön VPN kapcsolatot épít fel a PBX szerver felé. Viszont a VPN szervernek minden egyes felépült VPN kapcsolathoz, módosítania kell a saját routing tábláját. Ez más OS-eknél nem annyira automatizált folyamat, mint a mikrotik esetében. De mi lenne ha a helyi hálózat (amiben az ATA-k vannak) lenne a VPN szerver oldal, és a VPN kliens pedig a VPS-ben működő dolog. Vagyis az egyszerűség, és megbízhatóság érdekében ha csak 1 VPN kapcsolat lenne a helyi hálózat, és a virtuális szerver között az jó lenne. 2017. 08. 12. 23:29 keltezéssel, Sándor Fehér írta: Sziasztok! Még mindig ezzel szórakozok :) és elakadtam az "erdőben". Jelenleg a rendszer felépítése: VPS (egy adatközpontban, freepbx legújabb stable OS-al)>INTERNET >> pár darab okostelefon (zoiper titkosítva srtp-vel) I>>> MIKROTIK (OPENVPN) >> pár darab SPA3102 ata (titkosítás nélkül) A szerver eddig ott volt, ahol az ata-k és nem volt gond, hogy titkosítás nélkül mentek. Átköltöztettem a rendszert egy VPS-re és minden flottul megy, kivéve egy dolgot: A spa3102-k egy mikrotiken keresztül kapcsolódnak a vps-hez openvpn segítségével és azt vettem észre, hogy az RTP kommunikáció nem a vpn-ben történik, hanem csak a kontrol csatorna megy ott. Ha hívok egy külső telefonszámot, a kapcsolat felépülése a vpn-ben látható ( udp 5060) majd amikor a hívott fél felveszi a telefont, akkor a WAN oldalon látni az udp kommunikációt udp 1 és udp 2 között titkosítatlanul. Ez így nem túl biztonságos, mert lehallgathatóak a beszélgetések az ata-k között. Azt találtam ki, hogy csinálok még egy freepbx szervert az ata-k nak és a két freepbx-et kötöm össze titkosított IAX2-vel a SIP helyett. Működőképes az elgondolás? IAX2 tud teljes egészében a tunnelben működni? A kimenő hívások "lehallgatása" nem érdekel, de a belső telefonok, amik egymással beszélgetnek, az mindeképp titkos kell legyen! ui: Az okostelefonok a zoiperrel tudnak srtp-t/ztrp-t is és azokkal nincs ilyen gond. 2017. 06. 13. 13:44 keltezéssel, Fehér Sándor írta: Használ valaki reengert közülünk? ( VOIP, nordtelekom) Működik valakinek? Már minden jó, csak ez a szolgáltató nem megy! 2017. 06. 02. 9:37 keltezéssel, Fehér Sándor írta: Sziasztok! Ti nem találkoztatok a tárgyban említett jelenséggel? Tegnap óta egyik voip provideren sem tudok telefonálni. A jelenség annyi, hogy a hang nem megy át. Olyan mintha az RTP adatfolyam blokkolva lenne!! Több internetszolgáltatónál ezt tapasztalom. Ötlet vagy vélemény? Más is kínlódik ezzel? Üdvözlettel! ___ Techinfo mailing list Techinfo@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/ ___ Techinfo mailing list Techinfo@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/ ___ Techinfo mailing list Techinfo@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/ ___ Techinfo mailing list Techinfo@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/
Re: [Techinfo] VOIP SIP probléma több szolgáltatónál - folyt köv.
Sziasztok! Még mindig ezzel szórakozok :) és elakadtam az "erdőben". Jelenleg a rendszer felépítése: VPS (egy adatközpontban, freepbx legújabb stable OS-al)>INTERNET >> pár darab okostelefon (zoiper titkosítva srtp-vel) I>>> MIKROTIK (OPENVPN) >> pár darab SPA3102 ata (titkosítás nélkül) A szerver eddig ott volt, ahol az ata-k és nem volt gond, hogy titkosítás nélkül mentek. Átköltöztettem a rendszert egy VPS-re és minden flottul megy, kivéve egy dolgot: A spa3102-k egy mikrotiken keresztül kapcsolódnak a vps-hez openvpn segítségével és azt vettem észre, hogy az RTP kommunikáció nem a vpn-ben történik, hanem csak a kontrol csatorna megy ott. Ha hívok egy külső telefonszámot, a kapcsolat felépülése a vpn-ben látható ( udp 5060) majd amikor a hívott fél felveszi a telefont, akkor a WAN oldalon látni az udp kommunikációt udp 1 és udp 2 között titkosítatlanul. Ez így nem túl biztonságos, mert lehallgathatóak a beszélgetések az ata-k között. Azt találtam ki, hogy csinálok még egy freepbx szervert az ata-k nak és a két freepbx-et kötöm össze titkosított IAX2-vel a SIP helyett. Működőképes az elgondolás? IAX2 tud teljes egészében a tunnelben működni? A kimenő hívások "lehallgatása" nem érdekel, de a belső telefonok, amik egymással beszélgetnek, az mindeképp titkos kell legyen! ui: Az okostelefonok a zoiperrel tudnak srtp-t/ztrp-t is és azokkal nincs ilyen gond. 2017. 06. 13. 13:44 keltezéssel, Fehér Sándor írta: Használ valaki reengert közülünk? ( VOIP, nordtelekom) Működik valakinek? Már minden jó, csak ez a szolgáltató nem megy! 2017. 06. 02. 9:37 keltezéssel, Fehér Sándor írta: Sziasztok! Ti nem találkoztatok a tárgyban említett jelenséggel? Tegnap óta egyik voip provideren sem tudok telefonálni. A jelenség annyi, hogy a hang nem megy át. Olyan mintha az RTP adatfolyam blokkolva lenne!! Több internetszolgáltatónál ezt tapasztalom. Ötlet vagy vélemény? Más is kínlódik ezzel? Üdvözlettel! ___ Techinfo mailing list Techinfo@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/ ___ Techinfo mailing list Techinfo@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/ ___ Techinfo mailing list Techinfo@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/
Re: [Techinfo] VOIP SIP probléma több szolgáltatónál
Használ valaki reengert közülünk? ( VOIP, nordtelekom) Működik valakinek? Már minden jó, csak ez a szolgáltató nem megy! 2017. 06. 02. 9:37 keltezéssel, Fehér Sándor írta: Sziasztok! Ti nem találkoztatok a tárgyban említett jelenséggel? Tegnap óta egyik voip provideren sem tudok telefonálni. A jelenség annyi, hogy a hang nem megy át. Olyan mintha az RTP adatfolyam blokkolva lenne!! Több internetszolgáltatónál ezt tapasztalom. Ötlet vagy vélemény? Más is kínlódik ezzel? Üdvözlettel! ___ Techinfo mailing list Techinfo@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/ ___ Techinfo mailing list Techinfo@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/
[Techinfo] VOIP SIP probléma több szolgáltatónál
Sziasztok! Ti nem találkoztatok a tárgyban említett jelenséggel? Tegnap óta egyik voip provideren sem tudok telefonálni. A jelenség annyi, hogy a hang nem megy át. Olyan mintha az RTP adatfolyam blokkolva lenne!! Több internetszolgáltatónál ezt tapasztalom. Ötlet vagy vélemény? Más is kínlódik ezzel? Üdvözlettel! ___ Techinfo mailing list Techinfo@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/
