Llamadas de audio y vídeo
⚠ Rama experimental, no oficial. El Oasis oficial es https://github.com/epsylon/oasis · Volver a la portada
Dentro de una sala de Karvan hay un botón de llamada. El audio y el vídeo van directamente entre los participantes por WebRTC, cifrados de extremo a extremo por el propio protocolo.
Los botones
Están dentro de la sala, encima de los mensajes, y son cuatro:
| 📞 Call | Inicia la llamada. Es el que dispara la petición de permisos |
| 🎤 | Silencia y devuelve el micrófono sin colgar |
| 🎥 | Apaga y enciende la cámara sin colgar |
| ⛔ | Cuelga y devuelve la sala a su estado inicial |
Mientras hay llamada, los tres primeros se ponen encendidos y debajo aparece el estado
(mic ON · cam ON). El vídeo propio y el de los demás salen encima de la barra, en
una rejilla que se adapta al número de participantes.
Los mensajes de la sala siguen funcionando durante la llamada: no hay que elegir entre hablar y escribir.
Permisos de cámara y micrófono
En escritorio los pide el navegador directamente, la primera vez que inicias una llamada. No hay nada especial que configurar.
En la versión de Android hizo falta un envoltorio propio para poder concederlos, porque la APK oficial ni declara los permisos ni implementa el método que se los concede al contenido web. Aquí no aplica: eso lo resuelve el navegador. Ver Diferencias.
Sin servidores de terceros
Casi todas las aplicaciones con WebRTC traen configurado un servidor STUN público, normalmente de Google. Aquí no hay ninguno.
El motivo: un servidor STUN aprende la IP pública y el momento exacto de cada consulta. Con la configuración habitual, cada llamada le estaría diciendo a Google que ese usuario está llamando ahora. En un proyecto con esta postura sobre la privacidad, no se sostiene.
Por defecto solo se usan candidatos host: funciona en la misma red local y con routers domésticos amables. Se prefiere degradar a nada antes que a un tercero.
Si necesitas atravesar NAT
Con datos móviles o detrás de CGNAT hará falta un servidor TURN. La configuración va
en oasis-config.json:
"rtc": {
"stun": ["stun:tu.pub:3478"],
"turn": {
"urls": ["turn:tu.pub:3478"],
"secret": "<el static-auth-secret de tu coturn>",
"ttlSec": 3600
},
"relayOnly": false
}
Con secret se generan credenciales que caducan solas (mecanismo REST de coturn):
no hay usuarios que dar de alta y una credencial filtrada vale una hora.
Con relayOnly: true toda la media pasa por el TURN, de modo que ningún
participante ve la dirección IP del otro. Cuesta ancho de banda del servidor, pero es
lo que hay que activar si los participantes no deberían conocer sus IPs.
Si montas el TURN, endurécelo
Un TURN mal configurado es un relay abierto hacia la red interna del servidor.
Como mínimo, en turnserver.conf:
use-auth-secret
static-auth-secret=<32 bytes aleatorios, fichero con permisos 600>
realm=<tu dominio>
fingerprint
no-loopback-peers
no-multicast-peers
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=172.16.0.0-172.31.255.255
denied-peer-ip=192.168.0.0-192.168.255.255
denied-peer-ip=169.254.0.0-169.254.255.255
denied-peer-ip=100.64.0.0-100.127.255.255
denied-peer-ip=127.0.0.0-127.255.255.255
denied-peer-ip=<LA IP PÚBLICA DEL PROPIO SERVIDOR>
user-quota=12
total-quota=1200
max-bps=1500000
La última línea de denied-peer-ip es la que casi todo el mundo olvida:
no-loopback-peers impide llegar a 127.0.0.1, pero no impide que alguien pida un
relay hacia la IP pública de tu propia máquina y alcance así tu puerto de SSB o tu
servidor web. Sin esa línea, tu TURN es una puerta a tus propios servicios.
Compruébalo con turnutils_uclient contra una IP privada y contra la IP pública del
servidor: las dos deben fallar.
Probado entre dos participantes
Dos navegadores distintos en la misma sala, cada uno con su cámara. A la derecha, el vídeo que llega del otro participante, con su reloj corriendo.
Lo que ocurre por debajo, leído de la señalización de la sala:
- Los dos anuncian su presencia (
hello). - Se abre primero un canal de datos, y el indicador pasa de server relay (punto gris) a 🔒 P2P (WebRTC) en verde: desde ahí, los mensajes de la sala van directos entre navegadores sin tocar el servidor.
- Al pulsar Llamar se renegocia añadiendo
audioyvideo, y el otro lado responde. Comprobado en el SDP intercambiado.
Los participantes se identifican por navegador, no por identidad de SSB: dos navegadores del mismo nodo también se enlazan entre sí, que es como está hecha esta prueba.
Limitaciones honestas
- Sin TURN, con datos móviles casi nunca conectará. El CGNAT de los operadores lo impide, y por eso hace falta el TURN del pub.
- La señalización pasa por el servidor de la sala: un servidor comprometido podría colocarse en medio. La media va cifrada extremo a extremo, pero quien controla la señalización controla con quién crees que hablas.