VoIP, SIP y puente PSTN: entrando en el mundo de las telecomunicaciones

A principios de este año entramos en un terreno que hasta entonces solo conocíamos desde fuera: la telefonía. Para un sistema de atención al cliente había que gestionar llamadas entrantes y salientes, conectadas con la aplicación web existente. A continuación describimos lo que aprendimos en los primeros meses. A quien lleve años trabajando con VoIP esto le sonará; a quien lo mire por primera vez desde el desarrollo web quizá le ahorre unas cuantas semanas.

SIP no es HTTP, aunque lo parezca

SIP (Session Initiation Protocol) es un protocolo de petición y respuesta basado en texto, con cabeceras y códigos de estado, así que como desarrollador web uno cree que lo entiende. La primera sorpresa es que SIP solo se ocupa de establecer y terminar la llamada (INVITE, ACK, BYE): el audio en sí va por un canal completamente aparte, RTP, sobre UDP. La conexión entre ambos protocolos la establecen la dirección IP y el puerto descritos en el SDP, y ese es exactamente el punto donde se produce la mayoría de los fallos.

La segunda sorpresa son los códecs. G.711 (alaw, mulaw) usa 64 kbit/s de ancho de banda, sin compresión, y lo conoce cualquier dispositivo; G.722 ofrece banda más ancha, y Opus viene del mundo WebRTC y aguanta bien la variabilidad de la red. Si los dos extremos no encuentran un códec común, la llamada se establece, pero hay silencio. Si un elemento intermedio transcodifica, eso consume CPU y añade latencia. Conviene saberlo antes de dimensionar la infraestructura.

NAT y RTP: donde nace el audio unidireccional

El error clásico: la llamada se establece, una de las partes oye a la otra, pero la otra no. Esto es casi siempre un problema de NAT. La dirección IP privada que aparece en el mensaje SIP no es alcanzable desde el otro extremo y los paquetes RTP van a parar al sitio equivocado.

Lo que comprobamos en consecuencia en cada instalación:

• que la dirección externa del servidor SIP esté configurada explícitamente, y no la deduzca de la interfaz de red,
• que el rango de puertos RTP (normalmente varios miles de puertos UDP) esté abierto en el firewall, y que sea el mismo rango en el servidor y en la regla de firewall,
• que los componentes SIP que corren en Docker usen la red del host, o bien que el rango RTP esté publicado de forma explícita; el mapeo de puertos de la red bridge no es buena idea con varios miles de puertos UDP,
• que en el lado WebRTC haya un servidor STUN y, si hace falta, TURN, porque el navegador no sale de otra forma desde detrás de un NAT simétrico.

Ajustes como rtp_symmetric y otros del estilo “fíate de la dirección desde la que llegó el paquete” ayudan mucho, pero no lo resuelven todo.

Troncal SIP y puente PSTN

Para que nuestro sistema llame y reciba llamadas de números de teléfono reales hace falta conexión con la red telefónica pública (PSTN). Hoy eso lo proporciona casi siempre un operador a través de una troncal SIP: recibimos una cuenta SIP o autenticación por IP, y el operador encamina las llamadas hacia la red tradicional.

En nuestro caso, “puente PSTN” designa el componente que se sitúa entre nuestro propio sistema (aplicación web, clientes WebRTC, procesamiento de audio) y la troncal SIP. Esta capa se encarga del enrutamiento de las llamadas, de la normalización de los formatos de número (E.164), de la autenticación y de escribir los registros de llamada (CDR). Es importante que las credenciales de la troncal no lleguen nunca al lado cliente: el navegador se registra contra el puente, y el puente habla con el operador.

Una lección sobre la elección de troncal: conviene probar con varios operadores, porque la calidad de audio, el tiempo de establecimiento de llamada y el tratamiento de los códigos de error difieren de forma notable, y la documentación rara vez coincide con la realidad.

IVR y enrutamiento de llamadas

La respuesta de voz interactiva (IVR) es eso que todo el mundo conoce en su formato “pulse uno”. Técnicamente es una máquina de estados que reproduce ficheros de audio, espera tonos DTMF y en función de ellos redirige. Algunas cosas que importan en la práctica:

• el DTMF puede llegar de tres maneras (in-band como audio, como evento RTP RFC 2833, o como mensaje SIP INFO), y si dos elementos de la cadena acordaron modos distintos, la pulsación se pierde,
• la estructura del menú IVR no la guardamos en la configuración de la centralita, sino en la base de datos de la aplicación, para que el cliente pueda editarla él mismo,
• en el enrutamiento, el caso de “nadie lo coge” es al menos tan importante como la conexión exitosa: buzón de voz, solicitud de devolución de llamada o desvío deben estar siempre definidos.

Conectar el enrutamiento con la aplicación web (quién llama, qué cliente es, a quién debe ir) es el punto donde se encuentran la telefonía y el desarrollo de software, y donde vemos más valor de negocio.

Medición de la calidad de llamada

En telefonía, “funciona” no es binario. Una llamada puede establecerse y aun así entrecortarse, retrasarse o producir eco. Lo que medimos y registramos en cada llamada:

• pérdida de paquetes, jitter y tiempo de ida y vuelta a partir de los informes RTCP,
• el tiempo de establecimiento de la llamada (del INVITE al 200 OK),
• el motivo de finalización de la llamada (normal, rechazada, timeout, error de red) con su código de estado SIP,
• el valor MOS estimado, para poder mirar la tendencia con un único número.

Todo esto se almacena tanto como métricas de Prometheus como dentro del registro de llamada, de modo que ante una queja podemos reconstruir qué ocurrió exactamente.

La telefonía perdona mucho menos que la web: no hay botón de recargar, y el usuario oye al instante si algo no va bien. Eso es también lo que la hace atractiva: aquí la calidad de la infraestructura importa de verdad. En los próximos meses escribiremos también sobre módems GSM y envío de SMS, porque junto a la voz también acabó apareciendo eso.