Silencio en la línea: lo que nos enseñaron SIP, RTP y el puente PSTN

Cuando una llamada se establece y solo una de las partes oye a la otra, el culpable es casi siempre el NAT. Lo aprendimos en los primeros meses de este año, cuando un sistema de atención al cliente necesitó gestionar llamadas entrantes y salientes conectadas con una aplicación web ya existente. Hasta entonces conocíamos la telefonía solo desde fuera. Quien lleve años trabajando con VoIP encontrará aquí poco nuevo. A quien llegue desde el desarrollo web quizá le ahorre unas cuantas semanas.

Parece HTTP, pero no lo es

SIP (Session Initiation Protocol) es un protocolo de petición y respuesta basado en texto, con cabeceras y códigos de estado, de modo que un desarrollador web cree entenderlo. Sin embargo, SIP solo se ocupa de establecer y terminar la llamada (INVITE, ACK, BYE). El audio viaja por un canal completamente aparte, RTP, sobre UDP. Lo que une ambos protocolos son la dirección IP y el puerto descritos en el SDP, y ahí es exactamente donde se produce la mayoría de los fallos.

Los códecs son la segunda sorpresa. G.711 (alaw, mulaw) funciona sin compresión a 64 kbit/s y cualquier dispositivo lo entiende. G.722 ofrece banda más ancha. Opus procede 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 y reina el silencio. Si un elemento intermedio transcodifica, consume CPU y añade latencia. Hay que saberlo antes de dimensionar la infraestructura.

El audio en un solo sentido

El fallo clásico: la llamada se establece, una parte oye a la otra y la otra no oye nada. La dirección IP privada que figura en el mensaje SIP no es alcanzable desde el otro extremo, y los paquetes RTP acaban en el sitio equivocado.

En cada instalación comprobamos que:

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

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

Troncal y puente

Para llamar a números reales y recibir sus llamadas, un sistema necesita conexión con la red telefónica pública (PSTN). Hoy la proporciona casi siempre un operador mediante 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, el “puente PSTN” es el componente situado entre nuestro propio sistema (aplicación web, clientes WebRTC, procesamiento de audio) y la troncal SIP. Se encarga del enrutamiento de las llamadas, de normalizar los formatos de número (E.164), de la autenticación y de escribir los registros de llamada (CDR). Las credenciales de la troncal no deben llegar nunca al lado cliente: el navegador se registra contra el puente, y solo el puente habla con el operador.

Elegir troncal obliga a probar con varios operadores. La calidad de audio, el tiempo de establecimiento de llamada y el tratamiento de los códigos de error varían de forma notable, y la documentación rara vez coincide con la realidad.

Pulse uno

La respuesta de voz interactiva (IVR) es, técnicamente, una máquina de estados: reproduce ficheros de audio, espera tonos DTMF y en función de ellos redirige. En la práctica importan tres cosas:

• 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 la guardamos en la base de datos de la aplicación, fuera de la configuración de la centralita, para que el cliente pueda editarla él mismo,
• el caso de “nadie lo coge” importa al menos tanto como la conexión con éxito: buzón de voz, solicitud de devolución de llamada o desvío deben estar siempre definidos.

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

En cifras

En telefonía, “funciona” no es una respuesta de sí o no. Una llamada puede establecerse y aun así entrecortarse, retrasarse o producir eco. En cada llamada medimos y registramos:

• la pérdida de paquetes, el jitter y el 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 (normal, rechazada, timeout, error de red), con su código de estado SIP,
• el valor MOS estimado, para seguir la tendencia con un único número.

Todo se almacena como métricas de Prometheus y dentro del registro de llamada. 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 falla. Aquí la calidad de la infraestructura importa de verdad, y eso es lo que hace atractivo el terreno. En los próximos meses escribiremos también sobre módems GSM y envío de SMS, que aparecieron junto a la voz.