Por qué Retell creó su propio gateway SIP y WebRTC

Antes de que Retell creara su propio gateway, un proveedor líder conectaba las llamadas telefónicas y del navegador con los agentes de IA de Retell. La plataforma del proveedor sufría incidencias repetidas, y el proveedor tardaba de media entre 50 y 60 minutos en resolver cada una. No teníamos forma de resolver una incidencia más rápido. Algunas llamadas entrantes nunca llegaban a Retell, por lo que nuestros sistemas no tenían constancia de ellas. Nos enterábamos de las llamadas perdidas por los tickets de atención al cliente.

Queríamos controlar la calidad y la disponibilidad de cada llamada, así que creamos nuestro propio gateway SIP y WebRTC. Desde octubre de 2026, el gateway gestiona el 100% de las llamadas telefónicas y del navegador de Retell.

El gateway de Retell es el sistema que conecta las redes telefónicas y los navegadores web con los agentes de voz con IA de Retell. Habla SIP (Session Initiation Protocol), el estándar que usan los sistemas telefónicos para establecer y finalizar llamadas, y WebRTC (Web Real-Time Communication), el estándar que usan los navegadores para el audio en directo.

El gateway establece cada llamada, transporta el audio y lo mezcla para todos los participantes, y gestiona las transferencias, la escucha en directo (un supervisor oye la llamada mientras se produce), la toma de control (un supervisor o un agente humano sustituye al agente de IA en mitad de la llamada) y los cuelgues.

Para llevar a cabo estos cambios, sustituimos al proveedor en tres pasos.

Resultados clave:

• La latencia de infraestructura es aproximadamente un 90% menor: de 50 ms a 0,5 ms.
• Todas las llamadas telefónicas llegan primero a Retell, incluidas las que fallan.
• Las funciones de llamada se lanzan según el calendario de lanzamientos propio de Retell.

Qué hay entre quien llama y un agente de IA

Las demos de IA de voz suelen mostrar el último paso de un sistema complejo: el modelo que escucha y responde. Un agente telefónico en producción necesita mucho más que eso. Normalmente hay varias capas delante del modelo. Son las que deciden si una llamada se conecta, a qué velocidad se transmite el audio y qué ocurre cuando algo falla.

Una llamada a un agente de Retell pasa por estas cuatro capas:

1. La PSTN (red telefónica pública conmutada) es el sistema telefónico global. Las llamadas del navegador llegan desde un sitio web o una aplicación web.
2. Un session border controller (SBC) es el punto de entrada seguro de las llamadas telefónicas. Recibe las llamadas del exterior y decide adónde va cada una. Las llamadas del navegador no pasan por el SBC y se conectan directamente al gateway.
3. La capa de medios. Establece cada llamada, transporta el audio en ambas direcciones, lo mezcla para todos los participantes y ejecuta los controles de llamada, como las transferencias y los cuelgues. Las llamadas telefónicas llegan a ella por SIP. Las llamadas del navegador llegan por WebRTC. En Retell, el gateway es la capa de medios.
4. La infraestructura de IA de Retell. Es la que gestiona la conversación con quien llama.

Antes del gateway, el proveedor se encargaba de las capas 2 y 3. Retell ejecutaba un componente de software intermedio, llamado audio relay. El audio atravesaba la internet pública entre el proveedor y el relay, un salto de unos 50 ms, y después el relay lo pasaba a la infraestructura de IA de Retell.

Por qué la plataforma del proveedor se quedaba corta

La plataforma del proveedor estaba en la ruta de todas las llamadas, así que sus incidencias afectaban directamente a los clientes de Retell.

El proveedor tardaba de media entre 50 y 60 minutos en recuperarse de una incidencia. Durante algunas incidencias, las llamadas entrantes nunca llegaban del proveedor a Retell. Las llamadas perdidas no dejaban ningún registro de llamada ni ningún evento en nuestros sistemas, lo que significaba que no teníamos forma de detectar el fallo por nuestra cuenta.

Depender del proveedor causaba otros problemas:

• Los requisitos de los clientes dependían de lo que el proveedor admitiera, así que no podíamos lanzar nada que no fuera compatible.
• Era difícil cumplir los requisitos de seguridad y cumplimiento normativo a través de la plataforma del proveedor.
• El salto por la internet pública añadía latencia a cada llamada.
• La factura del proveedor ascendía a millones de dólares al año.

También evaluamos otros proveedores. Las evaluaciones confirmaron lo que ya pensábamos: para controlar la calidad del producto, teníamos que crear nuestro propio gateway.

Cómo sustituimos al proveedor en tres pasos

Cada paso trasladó una parte de la ruta de llamada a la infraestructura de Retell.

Colocar los session border controllers de Retell delante del proveedor

Desplegamos nuestros propios SBC y dirigimos toda la señalización SIP hacia ellos. Los clientes enviaban sus llamadas telefónicas a la dirección de Retell en lugar de a la del proveedor. También añadieron las direcciones IP de Retell a sus allowlists, las listas de direcciones desde las que sus sistemas telefónicos aceptan llamadas. Al principio, los SBC reenviaban todas las llamadas al proveedor.

Tener nuestros propios SBC nos dio el control del enrutamiento. A partir de entonces, todas las llamadas telefónicas llegaban primero a la infraestructura de Retell, donde podíamos verlas tanto si se conectaban como si no.

Durante un tiempo, las llamadas siguieron una ruta más larga. Entre los SBC de Retell y la infraestructura de IA de Retell, cada llamada salía de nuestra red hacia el proveedor y volvía. Por el camino atravesaba dos veces la internet pública. Las llamadas del navegador seguían yendo directamente al proveedor.

Trasladar las llamadas telefónicas al gateway por fases, del 1% al 100%

Después creamos el gateway y lo desplegamos detrás de los SBC, dentro de la red de Retell. Una vez activo el gateway, cada llamada telefónica podía seguir una de dos rutas: a través del proveedor o a través del gateway.

Los SBC elegían la ruta de las llamadas entrantes. La infraestructura de IA de Retell la elegía para las llamadas salientes. Aumentamos por fases la proporción de llamadas telefónicas del gateway: 1%, 5%, 10%, 20%, 30%, 50% y, por último, 100%. En la ruta del gateway, el salto entre los SBC y el gateway tarda unos 0,5 ms, porque ambos están dentro de la red de Retell.

Trasladar las llamadas del navegador al gateway con el SDK de WebRTC de Retell

Las llamadas del navegador eran las últimas que quedaban en el proveedor. Creamos nuestro propio SDK de WebRTC (kit de desarrollo de software), el código que usa un sitio web o una aplicación web para realizar llamadas desde el navegador, y enrutamos las llamadas del navegador a través del gateway.

Con las llamadas del navegador trasladadas, retiramos al proveedor y el audio relay. Ahora, una llamada permanece en la red de Retell desde el momento en que llega hasta que alcanza la infraestructura de IA de Retell.

Por qué la migración fue difícil

El objetivo era asumir el control sin cambiar ningún comportamiento del que dependieran los clientes. Lo difícil fue sustituir al proveedor durante llamadas en directo sin causar fricciones a los clientes. Las llamadas entrantes, las salientes, las transferencias, las llamadas del navegador y los controles de llamada tenían que seguir funcionando como antes durante toda la migración.

Eso suponía preservar cuatro cosas:

• Comportamiento del protocolo (cómo habla el gateway SIP con los sistemas del otro extremo de la llamada): los operadores y los sistemas telefónicos de los clientes tenían que obtener el comportamiento que esperaban.
• Sincronización del audio (cuándo llega el audio a cada lado de la llamada): el audio tenía que circular en ambos sentidos sin nuevos cortes ni retrasos.
• Permisos de los participantes (quién puede escuchar, hablar o iniciar una toma de control en una llamada): un supervisor que usara la escucha en directo tenía que conservar los mismos derechos.
• Semántica del ciclo de vida de la llamada (cómo empieza, cambia y termina una llamada): cada llamada tenía que empezar, transferirse y terminar igual, y enviar los mismos eventos a los sistemas de Retell.

El despliegue por fases nos permitió probar cada comportamiento con una pequeña proporción de llamadas telefónicas reales. Solo ampliábamos la proporción cuando el comportamiento se mantenía.

La principal lección que sacamos es que una migración de gateway como esta depende de controlar el enrutamiento, de una buena observabilidad y de pruebas que cubran todo el ciclo de vida de la llamada. Observabilidad significa poder ver qué está haciendo cada llamada en tiempo real.

La ruta de llamada de Retell hoy: SBC, gateway y SDK de WebRTC

Nuestra nueva ruta de llamada tiene tres partes.

Los SBC de Retell están de cara al exterior. Reciben la señalización SIP de los operadores y de los sistemas telefónicos de los clientes y, después, enrutan cada llamada.

El gateway hace el trabajo que antes hacía el proveedor. Establece las llamadas, transporta y mezcla el audio, y ejecuta los controles de llamada. Se comunica con la infraestructura de IA de Retell mediante HTTP y WebSocket, dos métodos estándar para que los servidores intercambien solicitudes y transmitan datos.

El SDK de WebRTC de Retell permite que los sitios y aplicaciones web envíen las llamadas del navegador directamente al gateway.

Los controles de seguridad y cumplimiento normativo forman parte del diseño. Incluyen acceso autenticado, permisos de los participantes, tratamiento del audio sensible y redacción de información sensible.

Qué cambió al tener nuestro propio gateway

Controlar la ruta de llamada significa que respondemos de cada aspecto de la calidad de una llamada.

Ya no dependemos de un proveedor para crear funciones de llamada. Un cliente del sector asegurador necesitaba cabeceras SIP personalizadas en los mensajes SIP BYE para una de sus campañas. Las cabeceras SIP son campos que transportan información adicional junto con una llamada. Un mensaje BYE es la señal que finaliza una llamada. En aquel momento, el proveedor no admitía cabeceras personalizadas en los mensajes BYE, así que creamos la función en el gateway. Como controlamos el código y el proceso de lanzamiento, lanzamos según nuestro propio calendario.

Ahora podemos cumplir por nuestra cuenta los requisitos de seguridad de un cliente (HIPAA, SOC 2, etc.). Retell también puede desplegar el gateway en nuevas regiones cloud cuando los clientes lo necesiten.

Cuándo no tiene sentido construir el tuyo propio

Un gateway no es el proyecto adecuado para un equipo que no tenga la capacidad de ingeniería necesaria para gestionar infraestructura de comunicaciones en tiempo real, ni los requisitos de producto que lo justifiquen.

Nuestro propio trabajo ha continuado después del lanzamiento. Gestionar un gateway requiere un equipo cualificado, además de una inversión continua en:

• Interoperabilidad telefónica
• Redes
• Procesamiento de medios
• Seguridad
• Monitorización
• Operaciones de guardia

La interoperabilidad telefónica consiste en mantener el gateway compatible con los numerosos operadores y sistemas telefónicos a los que se conecta.

Tener tu propio gateway también implica asumir la respuesta a incidencias, la planificación de capacidad, el mantenimiento y los despliegues seguros. Retell hizo esta inversión porque la calidad de las llamadas, la disponibilidad, la personalización y la mejora rápida son fundamentales para nuestro producto.

Consejos para equipos que quieran hacer lo mismo

Si tu equipo decide crear su propio gateway, esto es lo que nos funcionó:

1. Toma el control de tu punto de entrada SIP primero, para poder gestionar el enrutamiento y ver todas las llamadas telefónicas antes de sustituir la capa de medios.
2. Migra las llamadas telefónicas de forma gradual creando tu gateway detrás de tus SBC.
3. Trata las llamadas del navegador como una integración completa que incluye el SDK, la autenticación, el establecimiento de la conexión y el transporte de audio.
4. Incorpora controles de seguridad y cumplimiento normativo desde el principio, como hicimos con el gateway de Retell.
5. Mide la latencia, la calidad del audio y el comportamiento ante fallos durante toda la migración, incluidas las llamadas que fallan antes de llegar a tu aplicación.

Conecta tu sistema telefónico a Retell

Si los requisitos de telefonía han frenado el despliegue de tu IA de voz, empieza por nuestra guía de telefonía personalizada. Explica cómo conectar tu sistema telefónico a Retell mediante un SIP trunk (una conexión SIP directa entre dos sistemas telefónicos) y qué direcciones de Retell debes añadir a tu allowlist. Para más contenido técnico, consulta nuestros artículos sobre fiabilidad en tiempo real, Retell Workflows y Retell Memory.

Y si gestionas grandes volúmenes de llamadas o tienes requisitos de cumplimiento normativo estrictos, habla con nuestro equipo.