Integración de llamadas telefónicas (SIP) con OpenVidu
OpenVidu proporciona una infraestructura muy potente para realizar reuniones virtuales mediante tecnología WebRTC. Pero para proporcionar una experiencia de uso completa que no deje fuera a usuarios que, por temas de conectividad o de soporte de dispositivos, no puedan acceder mediante WebRTC, es necesario poder soportar e integrar medios de comunicación legacy, pero universales, como son las llamadas telefónicas.
Contexto
InterviewOpps permite a sus clientes realizar entrevistas de vídeo en vivo y bajo demanda. Las entrevistas bajo demanda permiten a los candidatos grabar respuestas en vídeo/audio a preguntas pregrabadas, mientras que las entrevistas en vivo permiten a las personas hablar en un formato de videoconferencia. Después de la llamada se proporcionan herramientas para la colaboración en la calificación de la entrevista al entrevistador y sus colegas.
Tanto para entrevistas bajo demanda como en vivo, InterviewOpps utiliza tecnología OpenVidu. Si bien las entrevistas bajo demanda permiten que los candidatos se tomen su tiempo, las entrevistas en vivo deben realizarse de forma sincrónica, por lo que cualquier dificultad técnica por parte del entrevistador o del entrevistado hará perder al menos el tiempo de 2 personas. Y con WebRTC, este tipo de dificultades no son infrecuentes. Es posible que los usuarios estén usando una conexión a Internet con un firewall, una conexión a Internet lenta o que su micrófono no funcione o no esté configurado. InterviewOpps descubrió que, en esta situación, los usuarios abandonan rápidamente la plataforma y utilizan una llamada telefónica o FaceTime.
La solución que eligió InterviewOpps para esto fue permitir a los usuarios usar un teléfono convencional para el audio. Esto sirve como respaldo, permitiendo a los usuarios no abandonar la plataforma. La forma en que funciona: los usuarios tienen que marcar un número de teléfono, luego introducir un código de entrevista seguido de un signo de almohadilla, y entonces están en la entrevista. Si también tienen vídeo proveniente de otro dispositivo, eso se combina con el audio proveniente del sistema telefónico.
El proyecto
El proyecto de InterviewOpps consiste en crear una plataforma de entrevistas, basada en OpenVidu pero ampliando la funcionalidad para permitir el acceso telefónico. Dentro del proyecto, Naeva Tec ha realizado un componente de aplicación que nos permite integrar estas llamadas telefónicas en una sesión de OpenVidu, tanto con llamadas entrantes como realizadas desde la aplicación. Las llamadas salientes se realizan asociando una dirección SIP que se asigna a un número de teléfono (o extensión, según el proveedor de telefonía) al que se puede llamar desde cualquier número de teléfono. A su vez, las llamadas salientes a cualquier número de teléfono se facilitan a través de la API que hemos desarrollado en Naeva Tec.
SIP, integrando con redes de telefonía
La conexión con la red de telefonía básica se realiza a través de un proveedor de acceso SIP. El desarrollo y el cliente final se han hecho usando los servicios de Twilio Programmable Voice. Pero cualquier proveedor de SIP puede usarse con la solución. De hecho, es recomendable implementar esta solución con una PBX (Private Branch eXchange, que es una red telefónica de una compañía que permite diferentes canales de comunicación como VoIP, ISDN, analógica), ya que, aun siendo factible la implementación de esta funcionalidad dentro de OpenVidu, es más sencillo y razonable integrar con una PBX.
Nuestra solución
Nuestra solución consiste en un componente de integración que expone una API REST para poder gestionar el soporte SIP de una sesión OpenVidu, realizar llamadas salientes y establecer llamadas telefónicas de modo similar al funcionamiento de OpenVidu, más un webhook que permite recibir eventos (llamadas entrantes, llamadas colgadas desde el teléfono, etc.). El establecimiento de una llamada significa que el audio proveniente del teléfono (y el vídeo, si lo soporta) se constituye en un nuevo publisher de la sesión al que el resto de participantes pueden suscribirse. Y el resto de publicadores en la sesión redirigirán su media al teléfono. Para el audio se realizará una mezcla de los audios. Si el teléfono soporta vídeo, la API REST permitirá decidir qué publicador de vídeo se reenvía al teléfono.
En este componente usamos el mismo modelo de publicadores/suscriptores que propone OpenVidu. Por defecto el teléfono se suscribirá a todo el resto de publicadores que haya en la sesión, pero la API REST proporciona la flexibilidad de que la aplicación pueda decidir qué flujos de audio suscribirá el teléfono (todos los que se suscriban se mezclarán antes de enviarlos al teléfono), y qué flujo de vídeo (único, no se realiza ningún tipo de composición) se reenvía al teléfono en caso de que soporte vídeo.
Internamente, este componente se integra con OpenVidu para la suscripción de media y para la publicación del audio en la sesión de OpenVidu. Para la integración con la red de telefonía SIP se usa Kurento (puede ser el mismo servidor Kurento de OpenVidu). Kurento nos proporciona casi todos los elementos necesarios para integrar con un servicio SIP: soporte del protocolo RTP, mezcla de audios, conmutación de vídeos (en caso de que el terminal SIP soporte vídeo).
Conclusión y lecciones aprendidas
Sin embargo, aunque Kurento y OpenVidu proporcionan un gran soporte de RTP/SRTP, lo que proporciona la base para integrar con una red SIP, la realidad es que las redes de telefonía SIP hacen uso del protocolo RTP/SRTP de formas que se adaptan poco a la implementación RTP realizada en Kurento. Concretamente, en el soporte del protocolo RTP realizado en Kurento se han encontrado las siguientes carencias:
- Falta de soporte para respuestas SDP provisionales usadas en el protocolo SIP mediante respuestas 183.
- Es habitual que las ofertas o respuestas SDP de la red SIP no incluyan SSRC asociados a los flujos de media, mientras que para Kurento esto es esencial para identificar una sesión de media.
- Y precisamente no los incluyen porque las centralitas SIP, cuando hacen algún tipo de conmutación de media, también cambian los SSRC e incluso la base de tiempos. Kurento no soporta este tipo de conmutaciones.
Para cubrir estas funcionalidades esenciales hemos creado un componente de Kurento y hemos contribuido a la comunidad de Kurento el SipRtpEndpoint, ya disponible como PR en el repositorio de GitHub de Kurento, que está siendo revisado y que esperamos ver pronto como módulo de Kurento.