Baresip / Baresip+

[taterp]

Zdravim, hledam nejakeho dobreho SIP klienta a cetl jsem nekde o Baresip. jake jsou vase zkusenosti s Baresip? Funguje ok? Co prichozi hovory - ok? A spotreba baterie?
Diky

[xsouku04]

S baresip zkušenost nemám. Mohu jen obecně. Problém je, že telefon nesmí usnout, protože za cca minutu a půl se rozpadne spojení přes NAT a nedozvěděl by se tak o příchozím hovoru. Tohle platí u protokolu UDP. TCP je na tom trochu lépe, protože se tak rychle nerozpadá, měl by vydržet minimálně 15 minut možná i déle. A jakmile se rozpadne, aplikace se to dozví a může znovu zaregistrovat.

Nejlepší je řešení s push notifikacemi, kdy aplikace může spát a probudí ji android systém, když přijde příchozí hovor.
Má to ale háček, ne u všech telefonů fungují push notifikace dobře, někdy tam může být také zpoždění, takže hovor lze propásnout. Push notifikace umí ACR phone.

Z všech ostatních SIP clientů pro android doporučuji použít protokol TCP, tím by mělo jít baterii šetřit trochu více, než s UDP.

[taterp]

S baresip zkušenost nemám. Mohu jen obecně. Problém je, že telefon nesmí usnout, protože za cca minutu a půl se rozpadne spojení přes NAT a nedozvěděl by se tak o příchozím hovoru. Tohle platí u protokolu UDP. TCP je na tom trochu lépe, protože se tak rychle nerozpadá, měl by vydržet minimálně 15 minut možná i déle. A jakmile se rozpadne, aplikace se to dozví a může znovu zaregistrovat.

Nejlepší je řešení s push notifikacemi, kdy aplikace může spát a probudí ji android systém když přijde příchozí hovor.
Má to ale háček, ne u všech telefonů fungují push notifikace dobře, někdy tam může být také zpoždění, takže hovor lze propásnout. Push notifikace umí ACR phone.

Z všech ostatních SIP clientů pro android doporučuji použít protokol TCP, tím by mělo jít baterii šetřit trochu více, než s UDP.

ACR phone vim, ale nevyhovuje mi, ze se stane defaultni aplikaci pro volani...

[taterp]

S baresip zkušenost nemám. Mohu jen obecně. Problém je, že telefon nesmí usnout, protože za cca minutu a půl se rozpadne spojení přes NAT a nedozvěděl by se tak o příchozím hovoru. Tohle platí u protokolu UDP. TCP je na tom trochu lépe, protože se tak rychle nerozpadá, měl by vydržet minimálně 15 minut možná i déle. A jakmile se rozpadne, aplikace se to dozví a může znovu zaregistrovat.

Nejlepší je řešení s push notifikacemi, kdy aplikace může spát a probudí ji android systém, když přijde příchozí hovor.
Má to ale háček, ne u všech telefonů fungují push notifikace dobře, někdy tam může být také zpoždění, takže hovor lze propásnout. Push notifikace umí ACR phone.

Z všech ostatních SIP clientů pro android doporučuji použít protokol TCP, tím by mělo jít baterii šetřit trochu více, než s UDP.

TCP? a co TLS?

[xsouku04]

TLS také používá TCP. Takže z hlediska průchodu přes NAT a uspávání telefonu by to mělo být stejné jako TCP.

[jadu]

Moje zkušenost je, že poskytovatelé internetu se k TLS chovají více s respektem než k běžnému TCP, protože do něj nevidí a nechají ho tedy více žít. Mělo by být:

• UDP - 180 s

• TCP SYN/WWW - 60 s

• ostatní TCP - 86 400 (nezažil jsem na mobilní síti)

Při loňském měření v létě

• UDP Vodafone 60 s

• UDP T-mobile/O2 120 s

• TCP Vodafone 60 s

• TCP T-mobile/O2 180 s

• TLS Vodafone 300 s

• TLS T-mobile/O2 3600 s

Operátoři překvapivě často 'optimalizují', tedy hodnoty mění, takže současné hodnoty mohou být jiné. Pokud se jedná o speciální přístup, např. privátní nebo firemní síť, tak záleží na nastavení security na perimetru, většinou to bývá Fortinet a jeho nastavení je v defaultu velmi striktní a operátoři neradi do toho zasahují. V době EET jsem zažil případ velké firmy, která měla značnou část ze svých prodejen připojenou vzduchem a Fortinet uzavíral při nečinnosti komunikaci po 180 s a změnu nastavení se podařilo u T-mobile prosadit až pod hrozbou odchodu.

[taterp]

Moje zkušenost je, že poskytovatelé internetu se k TLS chovají více s respektem než k běžnému TCP, protože do něj nevidí a nechají ho tedy více žít. Mělo by být:

• UDP - 180 s

• TCP SYN/WWW - 60 s

• ostatní TCP - 86 400 (nezažil jsem na mobilní síti)

Při loňském měření v létě

• UDP Vodafone 60 s

• UDP T-mobile/O2 120 s

• TCP Vodafone 60 s

• TCP T-mobile/O2 180 s

• TLS Vodafone 300 s

• TLS T-mobile/O2 3600 s

Operátoři překvapivě často 'optimalizují', tedy hodnoty mění, takže současné hodnoty mohou být jiné. Pokud se jedná o speciální přístup, např. privátní nebo firemní síť, tak záleží na nastavení security na perimetru, většinou to bývá Fortinet a jeho nastavení je v defaultu velmi striktní a operátoři neradi do toho zasahují. V době EET jsem zažil případ velké firmy, která měla značnou část ze svých prodejen připojenou vzduchem a Fortinet uzavíral při nečinnosti komunikaci po 180 s a změnu nastavení se podařilo u T-mobile prosadit až pod hrozbou odchodu.

Takze napriklad v pripade Vodafone a TLS mit a appce hodnotu max 300?

[jadu]

Takze napriklad v pripade Vodafone a TLS mit a appce hodnotu max 300?

Loni v létě to byla bezpečná hodnota .

Ono jde ještě o keep-alive. Pokud to jde přes TCP, tak to např. O2 nebere jako validní provoz a pokud není hovor, zavírá po 180 vteřinách. Jestliže to je TLS, tak to neignoruje a nechává to otevřené. Takže bych doporučil experimentovat. Zkusil bych půlení intervalů. tedy dát třeba 3 600 a po 3 500 vteřinách na telefon zavolat. Když to bude zvonit, pak to lze použít. Pokud nebude, dal bych 1 800 a pokus zopakoval po 1 700 vteřinách a případně pokračoval a jednou to začne chodit (pak lze jít zase s časem nahoru). Na jednom VOIP mám přes UDP u O2 registraci po 60 vteřinách a chodí to. Je to v routeru, tak mne baterka netrápí a datová spotřeba není nijak dramatická.