Spolehlivý SIP klient pro Android s dobrou integrací

[xsouku04]

[*] ACR Phone má nyní díky spolupráci s Odorik.cz vlastní push server, tedy spolehlivé příchozí hovory s menším vybíjení baterie. Podporuje více SIP linek současně a více registrací na jedné SIP lince z různých zařízení.

Jinak teda zkouším i ty příchozí hovory - dokud ACR aplikace jede, fungují ok. Až ji Android ukončí - a měla by být spuštěna push zprávou(?) - už se nedovolám. Viz ID 536286691-536286692-536286693 a 536286700-536286701. Ústředná hlásí "volaný účastník není dostupný". Debug mód v aplikaci předpokládám nepomůže - pak aplikace pořád jede a nepouští ji push(?). Nastavení mám snad správné, navíc jen to TLS+SRTP.

TLS nemáme ještě dostatečně otestováno. Mohlo by to tak být i tím TLS/TCP pro signalizaci. Telefon v tu dobu nebyl vůbec zaregistrovaný. Nejsem si jistý, jestli zabíjení aplikací je běžné chování androidu. Spíš bych řekl, že android jen aplikace uspává a v případě push je vzbudí. I když pokud vám fungují běžné příchozí hovory, asi ji umí i spustit. Jediné, s čím jsem se setkal já, že může probuzení trvat delší dobu, výjimečně až minutu. (většinou je okamžité) Mezitím hrajeme takové tóny, aby bylo jasné, že je třeba čekat. Předpokládám ale, že pokud vypnu nastavení spořiče baterie pro tu volací aplikaci, tohoto se zbavím. Nyní jsem to na svém telefonu aktivoval. I tak znamená push úsporu baterie a dat, protože se nemusí posílat keep alive.

[alfi]

TLS nemáme ještě dostatečně otestováno. Mohlo by to tak být i tím TLS/TCP pro signalizaci. Telefon v tu dobu nebyl vůbec zaregistrovaný. Nejsem si jistý, jestli zabíjení aplikací je běžné chování androidu. Spíš bych řekl, že android jen aplikace uspává a v případě push je vzbudí. I když pokud vám fungují běžné příchozí hovory asi ji umí i spustit. Jediný s čím jsem se setkal já, že může probuzení trvat delší dobu, výjimečně až minutu. (většinou je okamžité) Mezitím hrajeme takové tóny, aby bylo jasné, že je třeba čekat. Předpokládám ale, že pokud vypnu nastavení spořiče baterie pro tu volací aplikaci, tohoto se zbavím. Nyní jsem to na svém telefonu aktivoval. I tak znamená push úsporu baterie a dat, protože se nemusí posílat keep alive.

Můžu to zkusit bez TLS - nicméně to by na funkci nemělo mít vliv? Dorazí push do systému, probudí aplikaci a ta se teprve potom rozhodne, jestli použije TLS? Zabíjení aplikací na pozadí je standardní chování Androidů, mírně se liší podle výrobce (viz třeba https://dontkillmyapp.com/). Push zprávy takhle fungují i u jiných aplikací - dorazí notifikace z banky, slacku, emailu, chatu.. ani jedna z těch aplikací neběží a teprve doručený push ji znovu nastartuje? (nebo nenastartuje a musím sám z oznámení? A jde to i bez viditelného oznámení?). A nebo jsem nepochopil význam těch pushů - pokud aplikace musí běžet 24x7, tak ušetří max. ty keepalive (které mj. u TCP+TLS vydrží mnohem déle než UDP), ale spolehlivost to moc nezvedne. Reálně by mohlo stačit zobrazit tu push zprávu jako příchozí hovor, nastavit jí nějaký dlouhý oznamovací tón a aplikaci pustit, až uživatel vybere "přijmout hovor"? Ale detaily FCM netuším, už je to dlouho, co jsem s tím dělal, navíc Google ty API pořád mění

[xsouku04]

TLS nemáme ještě dostatečně otestováno. Mohlo by to tak být i tím TLS/TCP pro signalizaci. Telefon v tu dobu nebyl vůbec zaregistrovaný. Nejsem si jistý, jestli zabíjení aplikací je běžné chování androidu. Spíš bych řekl, že android jen aplikace uspává a v případě push je vzbudí. I když pokud vám fungují běžné příchozí hovory asi ji umí i spustit. Jediný s čím jsem se setkal já, že může probuzení trvat delší dobu, výjimečně až minutu. (většinou je okamžité) Mezitím hrajeme takové tóny, aby bylo jasné, že je třeba čekat. Předpokládám ale, že pokud vypnu nastavení spořiče baterie pro tu volací aplikaci, tohoto se zbavím. Nyní jsem to na svém telefonu aktivoval. I tak znamená push úsporu baterie a dat, protože se nemusí posílat keep alive.

Můžu to zkusit bez TLS - nicméně to by na funkci nemělo mít vliv? Dorazí push do systému, probudí aplikaci a ta se teprve potom rozhodne, jestli použije TLS? Zabíjení aplikací na pozadí je standardní chování Androidů, mírně se liší podle výrobce (viz třeba https://dontkillmyapp.com/). Push zprávy takhle fungují i u jiných aplikací - dorazí notifikace z banky, slacku, emailu, chatu.. ani jedna z těch aplikací neběží a teprve doručený push ji znovu nastartuje? (nebo nenastartuje a musím sám z oznámení? A jde to i bez viditelného oznámení?). A nebo jsem nepochopil význam těch pushů - pokud aplikace musí běžet 24x7, tak ušetří max. ty keepalive (které mj. u TCP+TLS vydrží mnohem déle než UDP), ale spolehlivost to moc nezvedne. Reálně by mohlo stačit zobrazit tu push zprávu jako příchozí hovor, nastavit jí nějaký dlouhý oznamovací tón a aplikaci pustit, až uživatel vybere "přijmout hovor"? Ale detaily FCM netuším, už je to dlouho, co jsem s tím dělal, navíc Google ty API pořád mění

Ve vašem případě nebyl ACR Phone v okamžiku příchozího hovoru vůbec zaregistrován. Push notifikaci posíláme, jen když je zrovna zaregistrován. Totiž ten náš outbound proxy push server nefunguje jen s Odorik.cz, ale se všemi, nebo téměř všemi VoIP SIP operátory na světě. Náš Push server se vloží do cesty mezi telefonem a VoIP operátorem (v našem případě sip.odorik.cz) a registrace a všechny hovory jdou přes něj. Kromě zvuku samotného, ten jde napřímo. Náš push server telefon pravidelně probouzí a hlídá, aby byl zaregistrovaný. V případě příchozího hovoru, se pošle ta push notifikace, aby se telefon znovu stihl přeregistrovat, a poté se hovor teprve pošle na telefon. To je ale možné udělat, jen když je telefon právě zaregistrován, protože jinak se o příchozím hovoru naše outbound proxy push server vůbec nedozví. Jde také o to, že majitel ACR Phone nechce manipulovat s nešifrovanými hesly všech uživatelů a tohle to umožňuje. Autorizaci a všechny SIP pakety jen přeposíláme a děláme jen nutné změny, aby to fungovalo, přístup k nešifrovaným heslům nepotřebujeme a nemáme. Proč je důležité to dělat takto obecně a odděleně? Aby mělo pro ACR Phone smysl s námi spolupracovat, a když to odladí s námi, odladí to zároveň pro naprostou většinu ostatních. A také se nám to lépe ladí, když je to oddělené a nemá to vliv na náš hlavní sip server sip.odorik.cz. Tedy proto si ACR phone může dovolit dát našim zákazníkům ACR Phone zdarma, protože to dá více práce a ne úplně každý to dovede. Bude si provozovat vlastní outbound push server, my jej provozujeme odděleně hlavně kvůli ladění.

Z ostatních programů na telefonování pro android zdarma nebo za rozumnou cenu má push server jen mizudroid a ten má omezení na jedinou linku. Ostatní to mají jen jako placený balíček s paušálním poplatkem, navíc pochybuji, že jim to ve všech případech funguje vždy dobře, přimět něco opravit např. Zoiper je téměř nemožné. ACR Phone má navíc tu perfektní integraci, podporu dělá přímo ten člověk, co to celé programuje.

Na mém telefonu to zatím funguje naprosto perfektně.

[alfi]

Ve vašem případě nebyl ACR Phone v okamžiku příchozího hovoru vůbec zaregistrován. Push notifikaci posíláme jen když je zrovna zaregistrován. Totiž ten náš outbound proxy push server nefunguje jen s Odorik.cz, ale se všemi, nebo téměř všemi VoIP SIP operátory na světě. Náš Push server se vloží do cesty mezi telefonem a VoIP operátorem (v našem případě sip.odorik.cz) a registrace a všechny hovory jdou přes něj. Kromě zvuku samotného, ten jde napřímo. Náš push server telefon pravidelně probouzí a hlídá aby byl zaregistrovaný. V případě příchozího hovoru, se pošle ta push notifikace, aby se telefon znovu stihnou přeregistrovat a poté se hovor teprve pošle na telefon. To je ale možné udělat jen když je telefon právě zaregistrován, protože jinak se o příchozím hovoru naše proxy vůbec nedozví. Jde také o to, že majitel ACR Phone nechce manipulovat z nešifrovanými hesly všech uživatelů a tohle to umožňuje. Autorizaci a všechny SIP pakety jen přeposíláme a děláme jen nutné změny aby to fungovalo. Proč je důležité to dělat takto obecně a odděleně? Aby mělo pro ACR Phone smysl s námi spolupracovat a když to odladí s námi, odladí to zároveň pro naprostou většinu ostatních. A také se nám to lépe ladí, když je to oddělené a nemá to vliv na náš hlavní sip server sip.odorik.cz. Tedy proto si ACR phone může dovolit dát našim zákazníkům ACR Phone zdarma, protože to dá více práce a ne úplně každý to dovede.

Z ostatních telefonu zdarma nebo za rozumnou cenu má push server jen mizudroid a ten má omezení na jedinou linku. Ostatní to mají jen jako placený balíček s paušálním poplatkem, navíc pochybuji, že jim to ve všech případech funguje vždy dobře. ACR Phone má navíc tu perfektní integraci.

To rozdělení přes proxy smysl dává. Jen "nebyl v okamžiku příchozího hovoru vůbec zaregistrován" teda zabrání spojení hovoru, pokud dojde k zabití aplikace na pozadí. Nemůže tam být nějaký delší timeout, třeba 24h od poslední registrace? Nebo teda moc nefunguje "Náš push server telefon pravidelně probouzí a hlídá aby byl zaregistrovaný", protože po několika hodinách aplikace zmizí. (a výsledek je v podstatě stejný, jako by sám telefon posílal keepalive = aplikace i spojení se musí udržovat naživu? )

[xsouku04]

To rozdělení přes proxy smysl dává. Jen "nebyl v okamžiku příchozího hovoru vůbec zaregistrován" teda zabrání spojení hovoru, pokud dojde k zabití aplikace na pozadí. Nemůže tam být nějaký delší timeout, třeba 24h od poslední registrace? Nebo teda moc nefunguje "Náš push server telefon pravidelně probouzí a hlídá aby byl zaregistrovaný", protože po několika hodinách aplikace zmizí. (a výsledek je v podstatě stejný, jako by sám telefon posílal keepalive = aplikace i spojení se musí udržovat naživu? )

Problém je hlavně v tom, že není moc VoIP operátorů, co podporuje TLS a SRTP. Proto to není tak otestováno a je možné, že je problém v samotném programu ACR phone. TLS používá TCP, a to prostě pro VoIP tak vhodné a dobře škálovatelné jako UDP. Třeba tam může být problém v tom, že TCP může docela dlouho timeoutovat i při krátkém přerušení nebo výpadku internetu. Naše Outbound proxy by měla ale fungovat i s jinými programy nebo hardwarovými telefony jako třeba microSIP. Jen tam nebude docházet k push, protože to není android. Je třeba to ještě testovat, abychom s jistotou věděli, kde je problém. Ten autor ACR phone minulý týden psal, jestli nám TLS a TCP funguje, aby to s námi mohl testovat, že si zákazník stěžuje, že mu to zlobí i bez naší proxy. Navíc měl mimulý týden dovolenou. Co se týče toho TLS, tak jsme dlouho nevěděli, jestli je to vůbec proveditelné. Ano je, ale ještě to musíme testovat.

Teď jsem si TLS zapnul a budu sledovat, jestli se mi registrace po dvou hodinách sama obnoví, a jestli budou vždy fungovat příchozí hovory. Pro uživatele odorik je ještě možnost si požádat o wireguard VPN a to používat namísto TLS/SRTP.

[alfi]

Problém je hlavně v tom, že není moc VoIP operátorů co podporuje TLS a SRTP. Proto to není tak otestováno a je možné, že je problém v samotném programu ACR phone. TLS používá TCP a to prostě pro VoIP tak vhodné a dobře škálovatelné jako UDP. Třeba tam může být problém v tom že TCP může docela dlouho timeoutovat i při krátkém přerušení nebo výpadku internetu. Naše Outbound proxy by měla ale fungovat i s jinými programy nebo hardwarovými telefony jako třeba microSIP. Jen tam nebude docházet k push, protože to není android. Je třeba to ještě testovat, abychom s jistotou věděli kde je problém. Ten autor ACR phone minulý týden psal jestli nám TLS a TCP funguje, aby to s námi mohl testovat, že si zákazník stěžuje, že mu to zlobí i bez naší proxy. Navíc měl mimulý týden dovolenou. Co se týče toho TLS, tak jsme dlouho nevěděli, jestli je to vůbec proveditelné. Ano je, ale ještě to musíme testovat.

Teď jsem si TLS zapnul a budu sledovat jestli se mi registrace po dvou hodinách sama obnoví a jestli budou vždy fungovat příchozí hovory. Pro uživatele o dorik je ještě možnost si požádat o wireguard VPN a to používat namísto TLS/SRTP.

Z toho, co píšete, je problém v tom "linka není přihlášena -> neposíláme push". TLS s tím nemá nic společného. Android aplikace z principu neumí jet v pozadí 24x7. Jednou za čas systém každou sestřelí (i třeba kvůli nedostatku RAM při spuštění nějaké náročné hry). Tj. pokud chcete řešit "spolehlivé příchozí hovory", je třeba umět probudit vypnutou aplikaci. Když to půjde, nemusíte ji pak ani udržovat aktivní. Cokoliv jiného je jen takové hraní si, že příchozí hovory pojedou 60% času místo 40%, ale spolehlivé to nebude

[xsouku04]

Z toho, co píšete, je problém v tom "linka není přihlášena -> neposíláme push". TLS s tím nemá nic společného. Android aplikace z principu neumí jet v pozadí 24x7. Jednou za čas systém každou sestřelí (i třeba kvůli nedostatku RAM při spuštění nějaké náročné hry). Tj. pokud chcete řešit "spolehlivé příchozí hovory", je třeba umět probudit vypnutou aplikaci. Když to půjde, nemusíte ji pak ani udržovat aktivní. Cokoliv jiného je jen takové hraní si, že příchozí hovory pojedou 60% času místo 40%

Ale tohle funguje. My vždy cca 6 minut před expirací pošleme speciální push, které slouží k tomu, aby si registrace obnovila. Tedy aplikace se vzbudí a zaregistruje na další dvě hodiny, a to mi s UDP výborně funguje.
S TCP může mít probouzení nějaký problém. Když si probudím notebook ze spánku, tak mi připojení přes SSH (TCP) také nějakou dobu timeoutuje, než mi dovolí se připojit znovu. Prostě proto, že to TCP spojení nejspíš uzavřel router po cestě, a tak se již neobnoví a timeoutuje v řádech minut. Nevím jistě, jestli je to ono, ale možná by to chtělo po probuzení, nebo při jakékoli změně připojení internetu všechny TCP spojení shodit a udělat nová. Nyní jsem na TLS, několikrát jsem se prozváněl a zatím to nespadlo. Ale kolega říká, že přes noc to spadne a už se to znovu nepřipojí, i když se pošle push.

[alfi]

Ale tohle funguje. My vždy cca 6 minut před expirací pošleme speciální push, které slouží k tomu, aby si registrace obnovila. Tedy aplikace se vzbudí a zaregistruje na další dvě hodiny a to mi s UDP výborně funguje.
S TCP může mít probouzení nějaký problém. Když si probudím notebook ze spánku, tak mi připojení přes SSH (TCP) také nějakou dobu timeoutuje, než mi dovolí se připojit znovu. Prostě proto, že to TCP spojení nejspíš uzavřel router po cestě a tak se již neobnoví a timeoutuje v rádech minut. Nevím jistě jestli je to ono, ale možná by to chtělo po probuzení, nebo při jakékoli změně připojení internetu všechny TCP spojení shodit a udělat nová. Nyní jsem na TLS, několikrát jsem se prozváněl a zatím to nespadlo. Ale kolega říká, že přes noc to spadne a už se to znovu nepřipojí i když se pošle push.

UDP NAT ale nemá timeouty v hodinách, tj. pokud spojení server->klient funguje, bude to ještě něčím jiným? (push při hovoru NAT znovu proštouchne?). Naopak to ssh je dobrý ukazatel timeoutu na TCP = dokud spojení neshodí server nebo NAT cestou, tak drží, cca hodiny, ne dny.

According to Section 4.3 of RFC 4787, the UDP timeout of a NAT should not be smaller than 2 minutes (120 seconds), except for selected, well-known ports. In practice, however, routers tend to use smaller timeouts. For example, OpenWRT 14.07 uses a timeout of just 60 seconds.
For TCP, the timeouts can be much larger, since TCP connections are usually terminated by an explicit FIN/FIN-ACK exchange. For established TCP connections, Section 5 of RFC 5382 specifies a timeout of no less than 2 hours 4 minutes (7204 seconds), and OpenWRT uses 7440 seconds.

Jinak pořád platí, že Android může aplikaci zabít kdykoliv bez ohledu na počítání timeoutu na proxy ("cca 6 minut před expirací pošleme speciální push"), tj. pokud push dorazí až po zabití aplikace, spojení se rozpadne - a neobnoví, dokud si toho uživatel nevšimne? (zkouším, přihlásím TLS, zabiju aplikaci - příchozí hovor se nedovolá, ale měl by). Nevím, jak dlouho to SIP přihlášení trvá - já bych se na obnovu x hodin starého spojení v nejistém stavu vykašlal a po pushi s příchozím hovorem telefon klidně znovu přihlásil?

Zkouším i to UDP - a chová se divně. Můžu volat, ale příchozí hovor nedorazí ani hned po přihlášení (např. 536513469). TCP se vůbec nepřihlásí (v aplikaci "end of file (PJ_EEOF)"), historie přihlášení na ústředně to vůbec nevidí.

[Kristovec]

Mám potíž : Na telefonech Nokia G60 5G a Vivo Y72 po jejich zapnutí nejde v aplikaci při odchozím hovoru vůbec žádný zvuk,napeosté ticho, je třeba nejprve jeden příchozí hovor a potom jde zvuk i u odchozího.

[xsouku04]

Mám potíž : Na telefonech Nokia G60 5G a Vivo Y72 po jejich zapnutí nejde v aplikaci při odchozím hovoru vůbec žádný zvuk,napeosté ticho, je třeba nejprve jeden příchozí hovor a potom jde zvuk i u odchozího.

Dělá to jen u VoIP hovorů? Podobný problém jsem měl také, i když se vyskytoval hodně vzácně, a já neslyšel jen vyzvánění. Pomohla změna zvukového zařízení. Je to i v tom návodu.