forum.odorik.cz

Dobry den,
opraveno, diky za nahlaseni.

Sent from my M2102J20SG using Tapatalk

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.

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.

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íš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.

WebSocket by mohl být ultimátní způsob, jak si zavolat z velmi restriktivních sítí.
Řekl jsem si, že před cestou mimo EU bych si to mohl někde vyzkoušet. Dobré místo na zkoušení je McDonald's.
V českých McDonaldech na jejich wifi nefunguje:
- VoIP (SIP)
- Telegram
- běžné VPN

Stránka https://wss.odorik.cz se tam vůbec neotevře. Nepomohlo by použití portu 443, namísto 444?

Harry píše: ↑stř 17. črc 2024 9:18:53 WebSocket by mohl být ultimátní způsob, jak si zavolat z velmi restriktivních sítí.
Řekl jsem si, že před cestou mimo EU bych si to mohl někde vyzkoušet. Dobré místo na zkoušení je McDonald's.
V českých McDonaldech na jejich wifi nefunguje:
- VoIP (SIP)
- Telegram
- běžné VPN

Stránka https://wss.odorik.cz se tam vůbec neotevře. Nepomohlo by použití portu 443, namísto 444?

Vypadá to, že kromě vyjmenovaných služeb, blokují vše. Tedy port 443 by asi pomohl, ale stejně by to nevolalo, pokud kromě vyjmenovaných služeb blokují vše. Zkuste https://ctrlv.tv/ a kliknout na Realtime sdílení. Pokud vám sdílení obrazovky funguje i v Mcdonaldu, mělo by být možné přes websocket i volat. Pokud ne, tak to také blokují.

Jinak by to asi chtělo takové VPN, u kterého se nepozná, že je to VPN a proto nejde moc blokovat. Tedy VPN co se tváří třeba jako přístup přes web.

Zkuste, jestli vám v Mcdonaldu funguje https://protonvpn.com/free-vpn To by mohlo být neuniverzálnější způsob, jak se vyhnout různému blokování.

Vyzkoušeno, funguje pro ERP https://www.odoo.com/documentation/mast ... /voip.html
Odchozí hovoy fungují
a příchozí jsem ještě nerozchodil

Používáte někdo Odoo.com?