problémy s voip telefonama gigaset

okoun

v poslední době jsem začal mít problémy s telefonama od gigasetu, zákazník si stěžuje, že se nemůže jeho telefon přihlásit k operátorovi, je jedno kterému. když se telefon restartuje tak stále nic, pomůžew vždy až to když telefonu změním vnitřní adresu a potom si načte novou tak se přihlásí, může mi někdo prozradit kde je problém?

nemá se někde něco specielného nastavit na natu? nemůže být problém že máme v síti více jak jednu konektivitu?

zero

a jak mas tu konektivitu rozdelenou zakaznikum? to mas BGP primar/zaloha nebo balancujes provoz? Neni mozny, ze se Ti vraci odpoved tou druhou cestou? Zkusil jsi dat primo verejku na ten telefon (bez NATu)? Mame Gigasetu asi 30, dve konektivity taky a tohle chovani nepozoruju.

okoun

veřejky na telefonech nejsou a nebudou, zase tolik jich nemáme :)

konektivita druhá je záložní a někdy se to přepne, je to pouze pomocí costů v ospf ale nemůže se stát že by kus tekl jinak, to ne.

spíš jestli nějak nezměnit časování na connections? mám to defaultní MK.

zero

to nevim. my mame connection na 12 hodin a funguje nam to v pohode.

okoun

u nás to je nastaveno na 1d

majklik

Z connection se uplatňuje generic-timeout na SIP provoz, což je default 10 minut.

Otázka je, zda máš v těch branách na net zapnutý SIP helper a případně, zda v těch telefonech je zapnutá STUN podpora. Jejich vhodnou kombinací to jde rozbít. Vtipné je, když se STUN naučí v telefonu, na jakou IP adresu se jeho spojení NATuje, tu zkusí cpát dovnitř UDP komunikace a SIP heleper to zkusí poladit. Pokud v té chvíli se ještě přepne linka a odchozí spojení na jinou IP, než si STUN právě myslí, tak dílo je dokonáno (I když by to gigáč tak za 5 minut měl zjistit).

Řadu operátorů samo od sebe rozbije nečekaně rychlá změna IP adresy toho NATu, když ti to přepne a pak blokuji přihlášneí na číslo třeba hodfinu/dvě.

Gigáče mám, dvě konektivity přepínající IPčka také a jede mi to OK. V RBčkách vypnutý SIP helper, časování defualt, v Gigáčích vypnutý STUN a čas obnovy registrace nastavenu na 1 minutu.

okoun

STUN byl vypnutý ale helper u zákazníka na SXt byl aktivní, na bráně je helper vypnutý.

hapi

Z connection se uplatňuje generic-timeout na SIP provoz, což je default 10 minut.

Otázka je, zda máš v těch branách na net zapnutý SIP helper a případně, zda v těch telefonech je zapnutá STUN podpora. Jejich vhodnou kombinací to jde rozbít. Vtipné je, když se STUN naučí v telefonu, na jakou IP adresu se jeho spojení NATuje, tu zkusí cpát dovnitř UDP komunikace a SIP heleper to zkusí poladit. Pokud v té chvíli se ještě přepne linka a odchozí spojení na jinou IP, než si STUN právě myslí, tak dílo je dokonáno (I když by to gigáč tak za 5 minut měl zjistit).

Řadu operátorů samo od sebe rozbije nečekaně rychlá změna IP adresy toho NATu, když ti to přepne a pak blokuji přihlášneí na číslo třeba hodfinu/dvě.

Gigáče mám, dvě konektivity přepínající IPčka také a jede mi to OK. V RBčkách vypnutý SIP helper, časování defualt, v Gigáčích vypnutý STUN a čas obnovy registrace nastavenu na 1 minutu.

tak to máš štěstí že ti to jde. Já sem jednomu dělal ballancing konektivit a první co odpadlo byly telefony. Jakmile je to poslalo druhou konektivitou tak smůla. Musel sem vyhradit určitý IPčka aby šli pouze jednou konektivitou a nikdy druhou jinak telefon mrtvej... asi blokování u operátora.

majklik

Proč štestí? Funguje mi to tak dobře v desítkách míst. :-)

Hele, že máš jedno RBčko a v něm dvě konektivity? Já mám všude 2 routery, na každého ISP jeden a přepínám je pomocí VRRP, který má spojení, ten přebere na LAN adresu brány na sebe...

Pokud máš router jeden, tak nesmíš zapomenout udělat to, že jak se přepne linka z ISPA na ISPB, tak musíš smazat obsah conntracku, jinak telefony nepůjdou (stejně jako většina dalších věcí používající UDP). Uvědom si, jedu přes ISPSA - telefon naskočí, začne se natovat na IPA, je o tom je záznam v conntracku, pak přepneš routu na ISPB, tak v conntracku je stále dál záznam, že se natuje na IPA, ale posílá se to linkou B a máš smůlu. Už se to nepřenatuje, NAT se vybere jen 1x při otevření záznamu v conntracku a pak už drží, dokud nechcípne... TCP spojení po chvíli pochcípou a nové se navážou už se správnou IPB a jedou, ale UDPčko se SIPem, kde telefon zoufale každých pár sekund přiživí contrack dalším pokuem o REGISTER/OPTIONS/..., tak má smůlu do doby, než mu ten contrack smažeš nebo se to vrátí na ISPA.

Tohle u těch dvou routeru a VRRP se řeší samo. :-)

okoun

no já si tedy myslím že je to také dost operátorem, třeba máme tu 4 operátory a jediný 802.cz s emi zdá že je proti tomu odolný, ostní: odorik, fayn, eri mají problémy.

hapi

Proč štestí? Funguje mi to tak dobře v desítkách míst. :-)

Hele, že máš jedno RBčko a v něm dvě konektivity? Já mám všude 2 routery, na každého ISP jeden a přepínám je pomocí VRRP, který má spojení, ten přebere na LAN adresu brány na sebe...

Pokud máš router jeden, tak nesmíš zapomenout udělat to, že jak se přepne linka z ISPA na ISPB, tak musíš smazat obsah conntracku, jinak telefony nepůjdou (stejně jako většina dalších věcí používající UDP). Uvědom si, jedu přes ISPSA - telefon naskočí, začne se natovat na IPA, je o tom je záznam v conntracku, pak přepneš routu na ISPB, tak v conntracku je stále dál záznam, že se natuje na IPA, ale posílá se to linkou B a máš smůlu. Už se to nepřenatuje, NAT se vybere jen 1x při otevření záznamu v conntracku a pak už drží, dokud nechcípne... TCP spojení po chvíli pochcípou a nové se navážou už se správnou IPB a jedou, ale UDPčko se SIPem, kde telefon zoufale každých pár sekund přiživí contrack dalším pokuem o REGISTER/OPTIONS/..., tak má smůlu do doby, než mu ten contrack smažeš nebo se to vrátí na ISPA.

Tohle u těch dvou routeru a VRRP se řeší samo. :-)

jistě, ale při použití PCC? tam asi moc řešeních není kromě používání pouze jednoho ISP pro VoIP. On tím tedy trpí i třeba přístup do banky.