Telefonía en LOR

Se avanzó en probar las llamadas desde Android y (creo) Ekiga con un servidor remoto.

Preliminares
Instalé un servidor SIP Freeswitch en google cloud con IP asignada en Brasil.

@strysg y @lmita en el hacklab realizaron llamadas de prueba exitosamente con el cliente SIP nativo en android.

esta configuración fue con una instalación de Freeswitch 1.6 básica (completa, con varios idiomas, etc.) en modo RTP proxy, es decir el audio RTP pasa por FS en ambas direcciones. en La Otra Red por las latencias entre diferentes nodos lo ideal (creo) sería pensar en modo “peer-to-peer” y posiblemente tener servidores (proxies) de multimedia aparte en algunos nodos. posiblemente no sea necesario y se podría usar el mismo modo proxy en LOR. esto también introduce temas cómo monitoreo de llamadas.

Pendientes

los siguientes pasos serían instalar y configurar el sistema básico localmente es decir permitir que uno o varios “usuarios” se registren al nodo FS y puedan llamarse y posiblemente recibir llamadas de Cotel con un adaptador PSTN.

pensando en ampliar el servicio a otros nodos, por ejemplo entre otras zonas de la ciudad, sería importante hacer pruebas y medir las latencias entre cliente-servidor y cliente-cliente para asegurar la calidad del audio.

actualmente estamos trabajando en instalar el Freeswitch localmente con @lmita para poder hacer más pruebas

Alternativas para Multimedia Interactiva (Llamadas) en LOR

sugiero que documentemos y debatamos diferentes alternativas para “telecomunicaciones” o llamadas y videollamadas en la otra red. en telefonía (incuyendo video) actualmente se cuenta con dos alternativas básicas, que incluso se pueden utilizar en paralelo y trabajan sobre una base muy similar: SIP y WebRTC.

SIP en términos generales, es un protocolo para llamadas, las cuales se denominan sesiones (session initiation protocol). permite establecer llamadas, videollamadas, enviar mensajes de texto y establecer group chats, además de servicios subyacientes (keepalive, intercambio de rutas o directorios telefónicos). usualmente SIP requiere un cliente y servidor configurados para comunicarse. en esta área existen varias alternativas de código libre como Asterisk, Freeswitch, OpenSIPs y Kamailio.

la gran ventaja de SIP es su universalidad, existencia de servidores y containers y clientes que pueden intercomunicarse. la desventaja es que puede ser complicado hacer que cada cliente y servidor se interconecte, lo cual requiere mucha configuración específica.

WebRTC es un conjunto de protocolos y/o tecnologías de multimedia interactiva los cuales se pueden resumir formalmente en un API para Javascript que se ejecuta en el mismo navegador web. con unas líneas de código se puede establecer una llamada directa entre clientes o hacia un servidor.

La ventaja de WebRTC es que cualquier navegador moderno lo soporta en teoría, y reduce la necesidad de instalar clientes locales. Las desventajas pueden incluir complejidad en la configuración, problemas propios a cada navegador web, la necesidad de contar con mayor infraestructura (y certificados SSL ya que WebRTC es seguro por defecto) y posible dependencia en otros servidores (ICE/STUN/TURN para temas NAT).

Para probar WebRTC propongo que utlizemos el Verto Communicator

1 me gusta

Me parecen buenas propuestas, tengo unas dudas sobre WebRTC por ejemplo si existe la dependencia permanete de un servidor como punto intermedio de conexión durante la llamada, es decir con WebRTC ¿hay posibilidad de pensar en modo “peer-to-peer”?.

Eso suena excelente :sunglasses:, desde el principio hemos querido hacer el servicio de llamadas gratis como uno de los servicios base para LaOtraRed.

Otro inconveniente en LOR sería los certificados SSL que por defecto sería autofirmados y los navegadores los reconocerían como no válidos o inseguros :sweat:. @lmita una vez logro SSL/TLS en LaOtraRed y los navegadores no se quejaban por que utilizaba un certificado real en sus páginas dentro de LaOtraRed, pero eso creo es otro tema.

El WebRTC sí permite peer-to-peer, sólo que usualmente requiere STUN/TURN/ICE para determinar la IP pública de cada participante. ICE en realidad es STUN, luego TURN, y luego usar un servidor intermedio si nada más funciona (sí el NAT o FW son muy restrictivos). En LOR en teoría no usaremos NAT entonces puede ser directa la conexión.

El SSL sí es un tema que no se puede obviar pero cómo mencionas en LOR la ventaja es que se tendrían los dominios completos digamos vozip1.chersky.lor y el certificado se puede generar con ese CN sin problemas.