Je to implementace SIP ALG. Jak píše Hapi, je to helper k tomu, aby fungovat SIP skrz NAT. Či-li to má význam jen v případě, že Mikrotik dělá NAT a za ním je schován VoIP SIP telefon, kterému má usnadnit (přesněji VoIP ústředně ke které je telefon přihlášen), aby fungoval jak má. Objevilo se to časem, prvně pro port 5060 (defualtní port pro SIP signalizaci), pak přidali i 5061, první tam byla podpora pro VoIP s H.323, ale to je dneska prakticky mrtvé ve prospěch SIP.
Z pohledu VoIP operátorlů je to jak červený hadr na býka. Hledání routeru s opravdu funkční implementací SIP ALG přirovnávají ke snaze hledání Svatého grálu - někteří tvrdí, že existuje, ale nikdy to ještě nikdo neviděl. SIP ALG je na tom stejně a většína implementaci zvládá jen jendoduché případy typu, kdy call flow je INVITE, "bla bla bla", BYE. Což platí tak pro malé VoIP operátory s jednou bednou. Pokud je větší a telefon se různě přehazuje mezi servery během fáze navazování hovoru, tak to dělá divné věci.
Takže obvkyle, když VoIP operátorovi reklamujete, že něco nefunguje, tak pokud zjistí, že je k zákazníku v cestě aktivní SIP ALG, tak první reakce je, vypněte to, teprve pak se s Váma budeme bavit. Např u zmíněné 802 se dalo v meziksichtu podívat ve statusu registrovaného telefonu, zda detekovali SIP ALG v cestě (pomiňme, že s oblibou odkazují nefunkčnost na aktivní SIP ALG i když tam není). Už dlouho nevyuživám, tka nevíém, zda ot tam stále je.
Popravdě nevím, jak je na tom aktuálně implementace v ROSu přesně, paketově jsme nezkoumal, má to hsitoricky za sebou pár pěkných omylů (např pokud byl helper zapnutý na routeru, který nedělal NAT, tak to prznilo SIP k nefunkčnosti).
Dneska snad všichni operátoři mají u sebe implementovánu podporu na straně ústředny pro žití s NAT, stejně tak většina telefonů má pro to podporu, takže funkce je zbytečná, lepší mít vypnuto. Smysl míá jen v určitém případě, kdy NAT v cestě je symetrický, ale to není případ ROSu.
Aktivní SIP ALG, když je hodně blbě udělán, tak nedovolí ani registraci telefonu, když je blbě napůl, tak třeba funguje jen odchozí hlas a další. Dost často přepisoval v SIP datech věci, co neměl. A pokud se blbje SIP ALG srazil s VoIP telefonem, co řešil NAT pomocí STUN, tak to dopadá ech zmateně, správně by na takové upravené pakety od telefonu už neměl šahat. Takže vypnout a nechat na VoIP operátorovi, ať si zdetekuje NAT a dle toho mění call flow nebo keep alive pro udržení NATu. Případně to nechat na telefonu, ať si s tím pohraje přes STUN, ICE, ... Podstatné je mít jen rozumně conntrack timeouty na UDP. Default je tam 10 sec/3 minuty, což dostačuje, protože keep alive na SIP úrovni obvkyle dělají operátoři cca do minuty a pokud to řeší STUN, tak to není víc jak 180 sec také (zaleží telefon kus od kusu). Ani pro prorážení děr pro RTP není potřeba, obvkyle se řeší snad už všude použitím symetrického RTP. Tam je vhodné, aby VoIP telefon měl vypnuté VAD (neposílání RTP streamu, když je ticho), pokud to náhodou umí (což je steně nežádoucí funkce, pokud je reálné předávání hovoru do TDM sítě, kvůli synchronizaci).
K tomu helperu pro FTP, ten je určen pouze pro zprovoznění aktivního FTP. Aktivní FTP bez helperu nefunguje (jiná možnost je UPNP přenastavneí routeru). Takže když ho vypnu a mám za NATem FTP klienta s podporou jen aktivního FTP (nebo před NATem FTP server jen s podporou aktivníého režimu), tak už není šance na přenos. Pro pasivní FTP není potřeba.
