Well ST100 a lokální Asterisk

25.8.2012 16:10 | Přečteno: 2040× | Hardware | poslední úprava: 25.8.2012 18:54

Pořídil jsem si WiFi SIP telefon Well ST100 a jal se ho zkoušet s domácím Asteriskem. Telefon se ale občas začal chovat dost podivně: v určitou chvíli se „zasekne“ a od té doby jsou všechny hovory „hluché“, tj. směrem do telefonu „nejde zvuk“. Zdá se mi ale, že jsem našel příčinu a workaround.

Nejdřív jsem se dlouze snažil hledat různá nastavení, jestli jsem něco nezvoral, ale všechno marně. Nakonec jsem překonal vrozenou lennost a spustil na to wireshark a nestačil se divit. RTP packety z lokálního serveru nešly ve chvíli závady na IP telefonu, ale byly směřovány na vnější IP celé sítě (ta je za NATem a některé porty má přesměrovány na specifické IP). Když jsem se podíval na začátek spojení, zjistil jsem, že už v prvním packetu tam telefon onu vnějšní adresu háže v rámci SDP.

Z toho mi vyplývá, že telefon má zřejmě naimplementován nějaký „geniální“ algortimus na obcházení NATu, který se aktivuje na první pohled nedeterministicky. Zřejmě to asi bude využívat nějaké cizí servery, ze kterých zjistí vnějšní IP adresu sítě a tu pak nabonzuje SIP serveru.

Jelikož hlásit to výrobci a požadovat po něm opravu je dost na dlouhý lokte (ale třeba si na to taky najdu čas), sáhl jsem prozatím k jednoduchému workaroundu - zakázal telefonu přístup do internetu. Takto nemůže zjišťovat, jaká je vnějšní IP adresa a tím ani dělat problémy. Zatím to vypadá, že to problém vyřešilo. Třeba to někomu pomůže, jinak je to docela sympatický telefon :=)

       

Komentáře

[Magog]

Jeden ze zásadních problémů SIPu je to, že neumí NAT. Tohle omezení se samozřejmě snaží všichni nějak obejít. Pokud se snaží telefon i ústředna, nastává problém. Popsaný scénář bych viděl jako ten problém, který nastal.

[Petr Tomášek]

Slušné koncové zařízení má někde v nastavení volbu „obcházet NAT“. Tenhle telefon to dělá bez ptaní a ještě jenom když „se mu zachce“. To je ten problém.

Jinak dnes už tohle většina běžných VOIP poskytovatelů tohle řeší na straně serveru (pomocí proxy, pokud vím)...

[pavlix]

Tenhle telefon to dělá bez ptaní a ještě jenom když „se mu zachce“. To je ten problém.

Ono taky záleží na tom, kde a jak jsi to kupoval :). Jestli jsi vybíral obchod podle ceny, tak se nediv. Je to stále relativní novinka a když to koupíš někde se starým firmware, tak to prostě fungovat ani nemůže.

[pavlix]

Jeden ze zásadních problémů SIPu je to, že neumí NAT.

To není tak úplně pravda.

[kralyk z abclinuxu]

Nečekal bych, že jseště v druhé půli roku 2012 budem řešit problémy s NATem. Kdo sakra zas zdržuje nasazení IPv6?

[pavlix]

Well ST100 IPv6 neumí vůbec.

[Petr Tomášek]

To nejsou problemy s NATem. To je problem s tim, ze koncove zarizeni se snazi byt prilis iniciativni a obchazet NAT, i kdyz to neni vubec potreba. (BTW, vsichni poskytovatele VOIP/SIP, co jsem zkousel, se s NATem umi dobre vyrovnat na zaklade server-side reseni).

IPv6? Nechapu, k cemu by mi to melo byt dobre. S IPv4 mi nic nechybi

[pavlix]

To nejsou problemy s NATem.

Pak chceš jistě tvrdit, že by ty problémy bez NATu nevznikly, nebo se mýlím?

BTW, vsichni poskytovatele VOIP/SIP, co jsem zkousel, se s NATem umi dobre vyrovnat na zaklade server-side reseni).

To je značně laický a konzumentský pohled. Kdybys o SIPu něco málo věděl, tušil bys, že je od začátku navržený tak, aby žádného prostředníka či poskytovatele nepotřeboval.

IPv6? Nechapu, k cemu by mi to melo byt dobre.

Není potřeba, abys tomu rozuměl :).

S IPv4 mi nic nechybi

Konzumentovi ani nic chybět nemůže. Konzumuje, co mu bylo předloženo. Když je úplně nejhůř, tak na to během konzumace nadává.

[Petr Tomášek]

To nejsou problemy s NATem.

Pak chceš jistě tvrdit, že by ty problémy bez NATu nevznikly, nebo se mýlím?

Bez internetu a počítačů by ty problémy taky nevznikly

BTW, vsichni poskytovatele VOIP/SIP, co jsem zkousel, se s NATem umi dobre vyrovnat na zaklade server-side reseni).

To je značně laický a konzumentský pohled. Kdybys o SIPu něco málo věděl, tušil bys, že je od začátku navržený tak, aby žádného prostředníka či poskytovatele nepotřeboval.

No a k čemu je takový SIP dobrý? Pokud chce člověk, aby jeho hovory terminovaly ve veřejné telefonní síti, tak bez nějakého poskytovatele stejně neobejde...

IPv6? Nechapu, k cemu by mi to melo byt dobre.

Není potřeba, abys tomu rozuměl :).

Nejsem tupá ofce, jako ty

[kralyk z abclinuxu]

IPv6? Nechapu, k cemu by mi to melo byt dobre. S IPv4 mi nic nechybi

No, internetová telefonie je v kostce o tom, že se dva lidí k sobě připojí a povídají si No a něco takového by se už z definice na IPv6 realizovalo/realizuje mnohem líp než na IPv4...

[Petr Tomášek]

Něco takového se už z definice na IPv6 realizuje úplně stejně dobře jako na IPv4...

[kralyk z abclinuxu]

Ne. Počet možných adres je součástí definice. Ty máš možná to štěstí, že IPv4 adresu máš, drtivá většina lidí ale tohle štěstí nemá, a jsou tedy nuceni drbat se levou nohou za pravým uchem v podobě NATů, Skypů a podobných radostí...

[Petr Tomášek]

Drtivé většině lidí něco jako veřejná IP adresa vůbec nechybí...

[kralyk z abclinuxu]

Já bych řekl, že chybí. Viz tento příklad z lidové tvorby... Oni samozřejmě nevědí, že jim chybí zrovna IPv6, protože nevědí, že co IPv6 je a že vůbec existuje. Ale to na věci nic nemění...

[Nikola Ciprich]

jakou mate verzi asterisku? tipl bych ze mate u peera pro tento telefon povoleno REINVITE...

[Petr Tomášek]

Je to Asterisk 1.6; ale žádný REINVITE jsem ve wiresharovi neviděl (bohužel jsem si to neuložil, anžto se blokování na firewallu zafungovalo. Kdybych to zkusil zase rozjet, tak na to potřebuju nějakou dobu, než se bug objeví...).

Ale nemyslím, že by to bylo kvůli REINVITE, telefon tam tu blbou adresu cpal hned v prvním packetu (INVITE). Tuším, že tam bylo ještě jednou INVITE, ale to kvůli autentizaci.

Nebo máte nějaké bližší info o problému s REINVITE? Díky

[Nikola Ciprich]

zkuste do konfigurace peera pridat canreinvite=no (a reloadnete sip). mozna namisto toho bude volba directmedia, zkuste pripadne pastnout vystup ze sip show peer ... , v nejake verzi * se to zmenilo a nechce se mi ted zkoumat ve ktere, ale nejspis az 1.8

jinak tenhle telefon mam v praci na testy, tak na to zkusim kdyztak mrknout..

[Bedňa]

Na obchádzanie NATu sa používa UDP protokol stačí prinútiť druhú stranu poslať odpoveď. Kedysi som sa s tým hral a napísal aj jeden projekt, pre neochotu testerov som sa na to vykašlal. Skúsenosti som predal nejakému IWTU, čo si na tom mal robiť diplomovú prácu, neviem či s tým niečo robil, alebo to zapadlo prachom.

[Kvakor]

Jenže bez spoluopráce třetí strany ten pokus o odpověď vypadá jako port scan, u klasického postupu (UDP hole punching) se na zjištění čísel portu na vnější straně NATu používá server s veřejnou IP, který protistranám pošle čísla portů druhé strany..

[Bedňa]

Tretia strana (server, verejná IP) práve vôbec nieje podmienkou, pre uľahčenie spojenia verejnú IP používa SIP ale napríklad Skype, nie len pre spojenie, ale celý dátový tok, s tým súviase odpočúvanie atď.

[Bedňa]

A technika sa nazýva Cross NAT.

[Ondrej 'SanTiago' Zajicek]

A jeste je dobre zminit, ze pokud mate bezny linuxovy NAT, tak vam zadny z techto postupu nepomuze, protoze Linux bezne dela symetricky NAT, na ktery tyto postupy nefunguji.

[pavlix]

Citation needed.

[Ondrej 'SanTiago' Zajicek]

Co presne chces citovat? To, ze Linux dela standardne symetricky NAT, nebo to, ze na symetricky NAT prevazna cast techto postupu nefunguje?

To prvni lze snadno overit jednoduchym experimentem, videt to je napriklad i z toho, ze ruzni klienti za (linuxovym) NATem mohou sdilet stejny port na NATu (coz umoznuje AFAIK jen symetricky NAT).

Ze na symetrickem NATu nejde treba STUN zminuje Wikipedia a je to celkem zrejme - kdyz kazda odchozi connection muze byt uplne jina, tak se tam neni moc ceho chytit.

Na druhou stranu ten linuxovy NAT se snazi nemenit porty pokud to jde, takze jeho chovani muze casto pripominat port-restricted cone NAT a muze byt tak detekovan a casto to muze i fungovat, ale podminka pro to, aby to tak fungovalo spolehlive (tedy ze NAT vyhradi port pro aktivni host:port za NATem), obecne splnena neni.

[pavlix]

To, ze Linux dela standardne symetricky NAT

Jo, tohle mě zajímalo. Já jsem takové experimenty nedělal, ale vždycky jsem měl za to, že na Linuxu UDP NAT-T funguje a odchozí porty že se nesdílí.

To prvni lze snadno overit jednoduchym experimentem, videt to je napriklad i z toho, ze ruzni klienti za (linuxovym) NATem mohou sdilet stejny port na NATu (coz umoznuje AFAIK jen symetricky NAT).

Tak ono je lepší vědět než jen otestovat, ale ani to jsem nedělal :).

Na druhou stranu ten linuxovy NAT se snazi nemenit porty pokud to jde, takze jeho chovani muze casto pripominat port-restricted cone NAT a muze byt tak detekovan a casto to muze i fungovat, ale podminka pro to, aby to tak fungovalo spolehlive (tedy ze NAT vyhradi port pro aktivni host:port za NATem), obecne splnena neni.

To bude asi to, co mě uvedlo v omyl. Takže řekněme při pár strojích za NATem s náhodnými zdrojovými porty je to ještě celkem použitelné. A jestli to dobře chápu, tak to striktně nedodržuje ani ten symmetric NAT, protože u toho by nebylo možné port detekovat s tak velkou pravděpodobností.

Takže to nejspíš nesplňuje ani definici symetrického NATu, ani definici restricted-cone NATu.

[Ondrej 'SanTiago' Zajicek]

Testoval jsem to a chova se to takto:

(zdroj a cil komunikace, C* za NATem, S* venku)
CA1:CP -> SA1:SP        NAT CA1:CP na port CP
CA2:CP -> SA2:SP        NAT CA2:CP na port CP
CA2:CP -> SA1:SP        NAT CA2:CP na nahodny port, CP nemuze pouzit

Tedy snazi se to zachovat zdrojovy port, i kdyz kvuli tomu zacne sdilet porty mezi ruznymi klienty. Oproti tomu restricted-cone NAT by uz v druhem kroku zvolil nahodny port a ten samy pouzil i ve tretim.

A jestli to dobře chápu, tak to striktně nedodržuje ani ten symmetric NAT, protože u toho by nebylo možné port detekovat s tak velkou pravděpodobností.

To je otazka jak presne interpretovat tu definici. IMHO ta definice nepozaduje, ze by to mapovani muselo byt vzdy nahodne. Spis bych to videl tak, ze v cone NATech plati dodatecny axiom (zdroj:port za NATem je jednoznacne identifikovan portem (a IP) NATu), zatimco u symmetric NAT ten axiom neplati.

[pavlix]

Pak by ale museli všichni přepsat i důsledky.

[Ondrej 'SanTiago' Zajicek]

??

[Filip Frank]

Klidně to pošlete na Joyce, s výrobcem komunikují a je celkem velká šance že to bude brzy opraveno.

[Petr Tomášek]

Jj, je to ve "fronte", tech veci na ne bude vic, tak to poslu vse zaraz