Dobrý SIP telefon pro Android - CSipSimple

[xtonda]

Hlavní problem všech kodeků s protokolem SIP a IAX je velký everhead (zbytečně poslaná data) v kterých je zvuk zabalaen. Viz. http://www.asteriskguru.com/tools/bandw ... ulator.php Třeba g729 má jen 8KBit, ale když se to celé dá do pkaetů už to má 23,63 Kb přes SIP a 20.5 Kbit přes IAX. Spex pak dovede dělat hovor při 2 Kbps s iaxem je to poak 14.5 Kbps a v SIPu 17.63 Kbps. Je to nic moc ale na domluvu bohatě stačí.
...
Asi by to chtělo si udělat nějakej svůj vlastní "protokol", kde bude overhead podstatně menší a využit se při tom dá stávající kodek. Přesně to asi udělal fring. Klidně mohl použít nějakej existující kodek jen jej úsporněji zabalil.

Hlavní problém je paketizace a overhead samotného IP/UDP (28 Byte na paket), IAX má overhead celkem minimální (4 Byte na paket), u SIP (RTP) je to pravda horší (12 Byte na paket). Fring to hlavně vyřešil tím, že jeden paket obsahuje tuším 80 nebo 100 ms audia, zatímco u SIP/IAX se typicky používá 20ms, takže Fring pošle jeden paket místo čtyř nebo pěti u SIP/IAX. Stačilo by u IAX použít 80 nebo 100 ms pakety a slušný kodek a jsme na úrovni Fringu. Jenže toto je zase nežádoucí z jiného hlediska - způsobuje to větší prodlevu a při ztrátě paketu větší narušení hovoru, čili při jen trochu slušnější konektivitě jsou dlouhé pakety na závadu.

[xsouku04]

V každém případě je to supr postřeh a mít možnost si někde nastavit 100ms audia by nebylo špatné.
Ostatně ty prodlevy při volání přes Edge jsou už tak jak tak hodně velké, takže nějakých 100 ms navíc nevadí.
A pokud se ztrácí pakety tak většinou se ztrácí i několik vteřin za sebou, takže to že jsou ve více paketech asi tolik nepomůže. Mohli bychom třeba na nějakém jiném portu nastavit iax na paketazaci 80 co to pak udělá ...

Vypadá to tak, že mobilním internetu je jiná vhodná paketizace než u jiného internetu a jedinej kdo na to přišel je fring.

Nevíte jakej požívá fring kodek ?

[d2-mac]

Q: Which codec does fring support?

A: Fring currently supports the following codecs and uses them in the following priority:

1. GSM–06.10
2. iLBC–13k3
3. G.711–ALaw
4. G.711–uLaw

http://info.fring.com/partners/faq/

[ViR]

Fring currently supports the following codecs and uses them in the following priority......

Jenže to jsou kodeky, používané mezi Fring-serverem a siproxy uživatele Fringu (např. odoričí), kde je vlastně Fring-server v postavení klienta. Nikoli mezi Fring-klientem a Fring-serverem. Tam je něco proprietárního, byť celkem jistě odvozeného z nějakého běžného kodeku.

Je dobré si uvědomit, že program Fring (ale i třeba Nimbuzz) pracuje se serverem SIP operátora, tedy třeba s Odorikem, nepřímo, dle schematu: Fring-program <-> Fring-server <-> Odorik. Zatímco např. CSipSimple pracuje dle schématu: CSipSimple <-> Odorik.

Dá se to představit asi tak, jako kdyby mezi Fring v mobilu a SIP operátora byla vložena ještě specializovaná PBX.

[ViR]

Mohli bychom třeba na nějakém jiném portu nastavit iax na paketazaci 80 co to pak udělá ...

Někdy v roce 2005 jsem s tímto experimentoval u SIPu s Petrem Styxem (tehdy ještě myslím u SoftPhone)
,kdy na telefonování na lince od UPC s pingem na sipproxy kolem 7 - 8 ms bylo s pakety i několikanásobně delšími než je běžných 20 ms docela dobré. Na mé straně byla použita Sipura SPA-2000, kodeky byly G.711 a G.729. Ústředna byla nastavena tak, že se přizpůsobila požadavku klienta na velikost paketu. A datový tok samozřejmě výrazně klesl (celkem to odpovídalo výpočtům).

To bylo ovšem ovlivněno tím, že zvyšování latence do 100 - 150 ms více méně nevadí, neb není uchem vnímána, nebo ještě neruší.
A pravdou je, že na GPRS s latencí kolem 250 - 350 ms už bude to zhoršení komfortu přidáním třeba 50 ms "relativně" malé. (U Fringu se běžně přidá 80 ms jen tím, že Fring-server je třeba v Izraeli nebo UK.)

[xtonda]

Jaký kodek je použit v proprietárním protokolu Fringu by byla zajímavá informace. Ale jinak je pro experiment s IAX a paketizací po delším časovém intervalu potřeba vyjít z toho co podporují aktuální IAX klienti, např. pro Android je konečně alespoň jeden rozumný - Zoiper a z toho co ten podporuje dává smysl akorát speex a iLBC.

Pokud jde o "A pokud se ztrácí pakety tak většinou se ztrácí i několik vteřin za sebou", tak to se bude dost lišit podle technologie sítě, u sítí typu Ethernet a příbuzných, což je určitým způsobem i wifi, kde platí 1 UDP datagram -> 1 Ethernet rámec to zdaleka platit nemusí.