Integración de llamadas telefónicas (SIP) con OpenVidu
OpenVidu proporciona una infraestructura muy potente para realizar reuniones virtuales mediante tecnología WebRTC. Pero parar 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 video en vivo y bajo demanda. Las entrevistas en video permiten a los candidatos grabar respuestas en video / 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 calificación de la colaboración 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 antiguo para audio. Esto sirve como respaldo que permite a los usuarios no abandonar la plataforma. La forma en que funciona, los usuarios tienen que marcar un número de teléfono, luego ingresar un código de entrevista seguido de un signo de almohadilla y luego están en la entrevista. Si también tienen video proveniente de otro dispositivo, eso se combina con el audio proveniente del sistema telefónico.
El proyecto
El proyecto 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 hemos 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.
Llamadas salientes que 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 por cualquier número de teléfono.
A su vez, las llamadas salientes a cualquier número de teléfono se facilitarán 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 un 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 presenta un 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 mas un webhook que permite recibir eventos (llamadas entrantes, llamadas colgadas desde el teléfono, etc.). El establecimiento de una llamada significará que el audio proveniente del teléfono (y el video si lo soportase) se constituye en un nuevo publisher de la sesión a la que el resto de participantes pueden suscribirse. Y del resto de publicadores en la sesión se va a redirigir el media al teléfono. Para los medias de audio se va a realizar una mezcla de los audios. Si el teléfono soportase video, el API REST permitirá decidir qué publicador de video 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 va a suscribir a todo el resto de publicadores que haya en la sesión, pero el 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 que flujo de video (único, no se realiza ningún tipo de composición) se reenvía al teléfono en el caso de que soporte video.
Internamente este componente integra con OpenVidu para la suscripción de media y para la publicación del audio a 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 protocolo RTP, mezcla de audios, conmutación de videos (en caso de que el terminal SIP soporte video).
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 en 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 el soporte de protocolo RTP realizada en Kurento se han encontrado las siguientes carencias:
- Falta de soporte para respuestas SDP provisionales usadas en el protocolo SIP mediante respuestas 183
- Es usual que las ofertas o respuestas SDP de la red SIP no incluyan SSRC asociados a los flujos de media, mientras que para Kurento 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 que hemos contribuido a la comunidad de Kurento el SipRtpEndPoint ya disponible como PR en el repositorio de GitHub de Kurento y está siendo revisado y próximamente esperamos verlo como módulo de Kurento.