Podpora volání přímo z webového prohlížeče

Podrobnější technické novinky a vůbec novinky a postřehy z VoIP.

Re: Podpora volání přímo z webového prohlížeče

Příspěvekod kovik » pon 02. srp 2021 10:51:39

Dobry den,
opraveno, diky za nahlaseni.

Sent from my M2102J20SG using Tapatalk
Uživatelský avatar
kovik
 
Příspěvky: 498
Registrován: stř 16. lis 2011 12:07:52

Re: Podpora volání přímo z webového prohlížeče

Příspěvekod tomik » čtv 14. črc 2022 14:54:06

Dobrý den,
je normální, aby vytáčení přes simpl5 (jak od nás, tak i z toho Vašeho klienta) trvalo přes 30-40 sekund než se spojí? Je to docela dlouhá prodleva.

Z výpisu registrovaných SIP to hlásí: (provedeno z Vašeho webového SIP klienta)

Dne 14.07.2022 v 14:38:07 hodin vaše zařízení IM-client/OMA1.0 sipML5-v1.2016.03.04 poslalo z IP adresy 77.95.41.xxx:5718 na IP adresu 89.185.255.43:443 protokolem TLS následující registraci:
REGISTER sip:sip.odorik.cz SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK3xeTww8391yJcznx7MDcCRZf85OUx3y8;rport
From: "757579"<sip:757579@sip.odorik.cz>;tag=TaUzwe9vOQIPqnUc04TT
To: "757579"<sip:757579@sip.odorik.cz>
Contact: "757579"<sips:757579@df7jal23ls0d.invalid;rtcweb-breaker=no;transport=wss>;expires=0;click2call=no;+g.oma.sip-im;+audio;language="en,fr"
Call-ID: 360f5674-202d-40ca-fda4-581222975bb6
CSeq: 28762 REGISTER
Content-Length: 0
Max-Forwards: 70
Authorization: Digest username="757579",realm="sip.odorik.cz",nonce="YtAOsWLQDYUsFYA/E/tBErSvCwnYXnzFKRnNpYA=",uri="sip:sip.odorik.cz",response="e2eaf91b093bc72d9b6c5995cf01bf09",algorithm=MD5
User-Agent: IM-client/OMA1.0 sipML5-v1.2016.03.04
Organization: Doubango Telecom

Náš server vyhodnotil zprávu jako: Registrace probíhá - stále nedokončena - možný problém s firewallem
---
Z web konzole prohlížeče to během vytáčení vypíše akorát několikrát:
onIceCandidate = gathering
---
ID hovoru, který se pak spojil z toho webu se SIP klientem: 475040078

Když to ale zkusím obráceně. Zavolat ze SIP do prohlížeče (příchozí hovor), tak se spojení provede hned.
tomik
 
Příspěvky: 3
Registrován: stř 24. čer 2015 10:39:33

Re: Podpora volání přímo z webového prohlížeče

Příspěvekod xsouku04 » pát 15. črc 2022 9:39:20

Také jsme se tím setkali. Vliv na to má nastavení v "expert mode". Myslím, že to byla položka ICE servers na [], ale nejsem si tím úplně jistý.
Zkuste a dejte vědět.
Uživatelský avatar
xsouku04
Administrátor
 
Příspěvky: 7656
Registrován: pát 15. říj 2010 11:11:44
Bydliště: Brno

Re: Podpora volání přímo z webového prohlížeče

Příspěvekod tomik » ned 17. črc 2022 0:34:55

Děkuji za odpověď a nasměrování.
Skutečně je to tím ICE serverem. Ovšem řešení je nastavit tam prostě nějaký STUN server, aby se to spojilo hned. Třeba od googlu [{ url: 'stun:stun.l.google.com:19302'}].
Když se nastaví pouhé [], tak to vyhledává ICE kandidáty. A podle internetu prý za každé síťové rozhraní. Tím se vytáčení pak prodlužuje.
A i když se nastaví STUN server, tak není vyhráno. Nemusí to fungovat pod VPN. Tady se píše něco o tom, že VPN to nemusí správně tunelovat a tak se nespojí se STUN serverem a změní se zase na to vyhledávání kandidátů.
tomik
 
Příspěvky: 3
Registrován: stř 24. čer 2015 10:39:33

Re: Podpora volání přímo z webového prohlížeče

Příspěvekod xsouku04 » ned 17. črc 2022 13:12:44

tomik píše:Děkuji za odpověď a nasměrování.
Skutečně je to tím ICE serverem. Ovšem řešení je nastavit tam prostě nějaký STUN server, aby se to spojilo hned. Třeba od googlu [{ url: 'stun:stun.l.google.com:19302'}].
Když se nastaví pouhé [], tak to vyhledává ICE kandidáty. A podle internetu prý za každé síťové rozhraní. Tím se vytáčení pak prodlužuje.
A i když se nastaví STUN server, tak není vyhráno. Nemusí to fungovat pod VPN. Tady se píše něco o tom, že VPN to nemusí správně tunelovat a tak se nespojí se STUN serverem a změní se zase na to vyhledávání kandidátů.


Děkuji za objasnění. Já jen dodán, že co se týče SIPu a STUN, panuje hodně dezinformací. Totiž STUN je teoreticky užitečný k tomu, aby mohl zvuk proudit mezi dvěma volajícímu napřímo nejkratší cestou, tedy napřímo mezi volaným a volajícím, kteří jsou za oba NATem. Nefunguje to ale úplně vždy pro všechny typy NATu, tedy vždy musí existovat nějaký proxy, který RTP (tedy zvuk případně video) přepošle.
V praxi u SIPu jde zvuk přes server v podstatě vždy, takže STUN je jen teoretický výmysl, který schová neveřejnou adresu a není vůbec k ničemu dobrý.

Podobně nerozumím tomu, proč by tento webrtc SIP client měl používat STUN, když vždy komunikuje jen se serverem na veřejné adrese, který ten provoz ve všech případech pro jistotu přeposílá. Asi je to podobně jako u čistého SIPu jen rozmar nějakých teoretiků. Nebo mi něco uniká?


Pokud bych ale dělal někdo webové videohovory, kde naprostá většina hovorů je mezi dvěma web klienty, pak je to něco jiného. STUN by mohlo zlepšit kvalitu a latenci naprosté většiny hovorů a serveru snížit datový provoz třeba o 95%, protože typ NATu přes který se STUN neumí protlačit je spíše vzácný. Pokud ale někdo používá webrtc pro hovory na mobilní telefony, STUN je nesmysl. Nerozumím tomu, proč ten STUN nejde prostě vypnout. A i když mu nastavím, aby žádný nepoužil pomocí "[]", nutně se snaží nějaký najít a tím začátek hovoru zdržuje. I když se mu nakonec nic najít nepodaří, hovor po zdržení normálně funguje, protože STUN ve skutečnosti není potřeba.
Uživatelský avatar
xsouku04
Administrátor
 
Příspěvky: 7656
Registrován: pát 15. říj 2010 11:11:44
Bydliště: Brno

Předchozí

Zpět na Novinky

Kdo je online

Uživatelé procházející toto fórum: Žádní registrovaní uživatelé a 20 návštevníků