Voláni přes SIP přímo v Android

[xsouku04]

Tak pokud si nastavím aby klient byl stále na příjmu, tak brání přejití telefonu do úsporného režimu deep sleep a to skutečně dost bere baterku. Ale já to používám jen pro odchozí volání, klienta pustím, zavolám si a zas ho vypnu, příjem řeším normálně přes GSM.

Doporučuji VoIP na telefonu požívat jen pro odchozí hovory. Kromě velké spotřeby baterie je tam problém v tom, že by vám mohl někdo na VoIP zavolat v době, kdy sice na internetu jste, ale ne dostatečně kvalitním, aby se dalo slušně volat. A pokud se např pohybujete na ulici, nebo dokonce jedete, je výskyt problému hodně pravděpodobný.

[trip2house]

Jsem v SIP volani uplný začátečník a proto jsem skoušel všechno možný ale pŕi volaní přes CsipSimple a nebo Zoiper mě nebylo dobře slišet ale po nastavení SIP klienta v android je to už mnohem lepší.. a jak tady už zaznělo: taky používam integrováného klienta jenom pro odchozí hovory a příjem normálně přes GSM.
No a problém s volánim na vypnuté čislo jak píše Michaels: je to akceptovatelná vada !

[xsouku04]

Jsem v SIP volani uplný začátečník a proto jsem skoušel všechno možný ale pŕi volaní přes CsipSimple a nebo Zoiper mě nebylo dobře slišet ale po nastavení SIP klienta v android je to už mnohem lepší.. a jak tady už zaznělo: taky používam integrováného klienta jenom pro odchozí hovory a příjem normálně přes GSM.
No a problém s volánim na vypnuté čislo jak píše Michaels: je to akceptovatelná vada !

Zkoušel jsem to nyní také. Pokud by ono falešné zvonění bylo jako jediná vada, mohli bychom možná android obelstít tak, že bychom se u nás na ústředně tvářili, jako že hovor je zvednut okamžitě. Pak by se zvuk korektně přenášel. Ve skutečnosti by byl ale zvednut a účtován podle skutečnosti. Výhoda integrovaného SIP clienta je ta, že lze snadno nastavit, aby se před každým hovorem dotázal, zda volat normálně nebo přes VoIP.

[michaels]

Zkoušel jsem to nyní také. Pokud by ono falešné zvonění bylo jako jediná vada, mohli bychom možná android obelstít tak, že bychom se u nás na ústředně tvářili, jako že hovor je zdvihl okamžitě. Pak by se zvuk korektně přenášel. Ve zkutečnosti by byl ale zdvednut a účtován podle skutečnosti.

Asi jsem to nepochopil. Čili cílový GSM telefon je vypnutý. Volám z android klienta. Vaše ústředna hovor zvedne, aby mě to falšeně nezvonilo, začne se mi účtovat poplatek, ale protože jsem se vlastně nikam nedovolal, tak platím za ticho??? toto proboha NEEE!!

[xsouku04]

Asi jsem to nepochopil. Čili cílový GSM telefon je vypnutý. Volám z android klienta. Vaše ústředna hovor zvedne, aby mě to falšeně nezvonilo, začne se mi účtovat poplatek, ale protože jsem se vlastně nikam nedovolal, tak platím za ticho??? toto proboha NEEE!!

Samozřejmě by se to muselo udělat tak, aby to nemělo vliv na účtování. Jediný rozdíl by byl, že by se přenášel zvuk i během zvonění, které by pro tento "zabagavoaný android software" se jevilo, jako že už je to zvihnuté a tedy byly by slyšet i ty případné hlášky o nedostupnosti a podobně.

Docela nedovedu pochopit, že tento v podstatě 4 roky starý bug nikdo od googlu neopravil.
Při té příležitosti bychom mohli nasadit nějaký rozumný jitter buffer jako třeba 200 ms, tedy volání z androidu by rázem bylo mnohem použitelnější.

[michaels]

"Ve zkutečnosti by byl ale zdvednut a účtován podle skutečnosti." -> "Samozřejmě by se to muselo udělat tak, aby to nemělo vliv na účtování."

No já jen že jste psal v tom prvním příspěvku, že "by byl účtován podle skutečnosti", tak jsem to tak pochopil.

Za mě mi to nevadí, že to zvoní, i když je dotyčný mimo signál. I když chápu, že někdo si pak může myslet, že mu dotyčný zavolá zpět, když uvidí zmeškaný hovor, který vlastně neuvidí. Ale dotyčnému pak přijde vlastně SMSka, že se mu někdo snažil dovolat, co byl mimo signál.
Čili asi s tím není třeba nic dělat

[xtonda]

Při té příležitosti bychom mohl nasadit nějaký rozumný jitter buffer jako třeba 200 ms, tedy volání z androidu by rázem bylo mnohem použitelnější.

Již jsem to tu linkoval viz viewtopic.php?f=14&t=2491&start=80#p27985
a přidám další odkaz http://www.cisco.com/c/en/us/support/do ... tails.html, informace od Cisco snad nikdo nebude zpochybňovat, odcituji zajímavou pasáž

The generally-accepted limit for good-quality voice connection delay is 200 ms one-way (or 250 ms as a limit). As delays rise over this figure, talkers and listeners become un-synchronized, and often they speak at the same time, or both wait for the other to speak. This condition is commonly called talker overlap. While the overall voice quality is acceptable, users sometimes find the stilted nature of the conversation unacceptably annoying.

Čili 250 ms se považuje za limit pro zpoždění na celé trase v jednom směru, vyčerpat 80 % této hodnoty na jeden buffer je prostě příliš. Navíc jak to souvisí s Androidem? Ten je sice znám svým zpožděním audia, ale ještě jsem nečetl, že by způsoboval Jitter, rozhodně ne pokud je telefon v pořádku a má přiměřenou HW specifikaci.

[michaels]

Při té příležitosti bychom mohl nasadit nějaký rozumný jitter buffer jako třeba 200 ms, tedy volání z androidu by rázem bylo mnohem použitelnější.

Ale (snad nejen) já si nemyslím, že by byl s VoIP přes Zopier, CSimple či přímo nějaký android klient nějaký problém. Tak proč něco měnit všem?
A vždyť jitter buffer se dá už nyní přidat uživatelsky pro ty, co by to chtěli používat, ne? Stačí se připojit na port 6699 nebo vytočit *089 před číslem?
více na http://www.odorik.cz/w/internet

Rozhodně nám nechte možnost volby! Proto jsme, my zákzaníci, s VoIP u vás - že?

[xsouku04]

Při té příležitosti bychom mohl nasadit nějaký rozumný jitter buffer jako třeba 200 ms, tedy volání z androidu by rázem bylo mnohem použitelnější.

Již jsem to tu linkoval viz viewtopic.php?f=14&t=2491&start=80#p27985
a přidám další odkaz http://www.cisco.com/c/en/us/support/do ... tails.html, informace od Cisco snad nikdo nebude zpochybňovat, odcituji zajímavou pasáž

The generally-accepted limit for good-quality voice connection delay is 200 ms one-way (or 250 ms as a limit). As delays rise over this figure, talkers and listeners become un-synchronized, and often they speak at the same time, or both wait for the other to speak. This condition is commonly called talker overlap. While the overall voice quality is acceptable, users sometimes find the stilted nature of the conversation unacceptably annoying.

Čili 250 ms se považuje za limit pro zpoždění na celé trase v jednom směru, vyčerpat 80 % této hodnoty na jeden buffer je prostě příliš. Navíc jak to souvisí s Androidem? Ten je sice znám svým zpožděním audia, ale ještě jsem nečetl, že by způsoboval Jitter, rozhodně ne pokud je telefon v pořádku a má přiměřenou HW specifikaci.

Děkuji za upozornění. Opravdu nejenom cisco (kterému bych zrovna já moc nevěřil) píše o tom, že zpoždění nad 200 ms začíná být výrazně nepříjemné. Že ping do Vietnamu byl přes 200ms a přitom hovor se zdál být kvalitní, je tím, že ping je cesta tam i zpět. Kdežto zde mluvíme jen o jednom směru. Že jsem si toho při několika testovacích hovorech s jitter bufferem 300ms nevšiml, není tak směrodatné. Možná je to trochu profesionální deformace, kdy mne trochu ozvěny nebo zpoždění navíc nijak nevyvede z míry. Jenom by mne ještě zajímalo, jaké zpoždění dosahují mobilní sítě při hovorech v rámci ČR? Pokud si zavoláte v rámci jedné místnosti, je tam zpoždění docela silně cítit, přesto to jinak neruší.
Android OS někdy sám o sobě způsobuje nějaký jitter, ale je to spíše výjimečné.

[xsouku04]

Rozhodně nám nechte možnost volby! Proto jsme, my zákzaníci, s VoIP u vás - že?

Samozřejmě, že by zde byla možnost volby. Prostě další možnost nastavení u dané linky.