IP adresy odorik pro firewall

[Eter]

Chtěl jsem díky bezpečnosti, povolit VOIP zařízením jen IP adresu odoriku, ale kdyz mam ve firewalu sip.odorik.cz (81.31.45.51) A zadnou jinou,
tak sice hovory zvoní ale nefunguji, koukal jsem na firewalu a UDP komunikace jela jeste na IP 89.185.255.45, je někde seznam ip adres nebo
dns seznam adres, aby pri zmene jsem to nemusel měnit, který musím povolit aby mi hovory fungovaly korektne.

[xsouku04]

Ano je to tak. sip.odorik.cz je jen pro signalizaci, na RTP, tedy zvuk samotný se používají různé jiné ip adresy.
Máme rozsahy: 89.185.255.32/27 a 81.31.45.32/27

[Joe1vm]

Dobrý den,
rád bych se vrátil k tomuto tématu.
Během hovoru vidím na firewallu probíhající spojení z IP adresy telefonu, např. portu 16472 s IP adresou 81:30.45.56 např. s portem 20362 (RTP). Vše probíhá v pořádku.
Ale pravidelně každých pět vteřin mi přichází na vstup routeru packet z téže adresy z portu +1 (v tomto případě 20363) na port mé IP adresy, port +1 (tedy 16472). a jelikož nepatří k žádnému spojení, tak ho router po právu zahazuje.
Můžete mi prosím poradit o co jde a k čemu packety slouží? (jestli je potřeba je pustit dovnitř?:-)
Díky moc.

[xsouku04]

Dobrý den,
rád bych se vrátil k tomuto tématu.
Během hovoru vidím na firewallu probíhající spojení z IP adresy telefonu, např. portu 16472 s IP adresou 81:30.45.56 např. s portem 20362 (RTP). Vše probíhá v pořádku.
Ale pravidelně každých pět vteřin mi přichází na vstup routeru packet z téže adresy z portu +1 (v tomto případě 20363) na port mé IP adresy, port +1 (tedy 16472). a jelikož nepatří k žádnému spojení, tak ho router po právu zahazuje.
Můžete mi prosím poradit o co jde a k čemu packety slouží? (jestli je potřeba je pustit dovnitř?:-)
Díky moc.

To bude RTCP. https://cs.wikipedia.org/wiki/Real-time ... ocol_(RTCP)
Slouží k informování druhé strany, kolik paketů se směrem od ní ztratilo/opozdilo.

Moc jsem se tím nezabýval, ale co jsem si všiml, vypadá to, že většina VoIP zařízení to nedělá korektně, pokud vůbec, takže z toho nelze moc vyčíst/spolehnout se. Kdyby to dělala korektně všechna koncová VoIP zařízení, tak bychom mohli mít přehled o kvalitě zvuku v obou směrech. Takto máme přehled ve kvalitě směrem k nám. Podobně by mohlo mít přehled samotné zařízení a hlásit to samotnému uživatelovi.
Myslím, že aby se otevřel průchod přes NAT, musel by vaše VoIP zařízení to RTCP posílat také. Pokud to nedělá, protože to soudruh výrobce nějak nedodělal, pakety směrem od nás se k zařízení nedostanou, protože se jim neotevře NAT, což ale zjevně nevadí, protože by to stejně nikdo nečetl .

V SIPu je více takových nedomyšlených věcí, které se v praxi moc nepoužívají. Např. v SIPových hlavičkách se to hemží IP adresami, které jsou kvůli použitému NATu nesmyslnými, a proto na ně obvykle nikdo nehledí...

[Joe1vm]

To bude RTCP. https://cs.wikipedia.org/wiki/Real-time ... ocol_(RTCP)
Slouží k informování druhé strany, kolik paketů se směrem od ní ztratilo/opozdilo.

Moc jsem se tím nezabýval, ale co jsem si všiml, vypadá to, že většina VoIP zařízení to nedělá korektně, pokud vůbec, takže z toho nelze moc vyčíst/spolehnout se. Kdyby to dělala korektně všechna koncová VoIP zařízení, tak bychom mohli mít přehled o kvalitě zvuku v obou směrech. Takto máme přehled ve kvalitě směrem k nám. Podobně by mohlo mít přehled samotné zařízení a hlásit to samotnému uživatelovi.
Myslím, že aby se otevřel průchod přes NAT, musel by vaše VoIP zařízení to RTCP posílat také. Pokud to nedělá, protože to soudruh výrobce nějak nedodělal, pakety směrem od nás se k zařízení nedostanou, protože se jim neotevře NAT, což ale zjevně nevadí, protože by to stejně nikdo nečetl .

V SIPu je více takových nedomyšlených věcí, které se v praxi moc nepoužívají. Např. v SIPových hlavičkách se to hemží IP adresami, které jsou kvůli použitému NATu nesmyslnými, a proto na ně obvykle nikdo nehledí...

Dobrý den.
Díky moc za vysvětlení. Je to přesně, jak jste napsal. Soudruh výrobce to má zvládnuto, ale uživatel moc ne.. Stačilo nastavit RTCP Tx Interval: na nenulovou hodnotu, čímž se samozřejmě otevřelo spojení přes NAT. Pak se dají na web rozhraní zařízení nalézt informace o spojení jako např. Round Trip Delay. Ale který normální smrtelník by to četl to fakt nevím.
Každopádně díky za rozšíření obzoru.