Transcodificación AMR a G.711 en el SBC: cómo las redes modernas conectan la voz móvil con la voz IP

Las redes móviles y las redes de voz IP rara vez utilizan el mismo códec de audio. Los operadores móviles usan por defecto Adaptive Multi-Rate (AMR), el códec diseñado para enlaces de radio celular. Los IP-PBX empresariales, los SIP trunks, los centros de contacto y la PSTN en general operan casi universalmente con G.711. Cuando una llamada cruza esa frontera, en algún punto del camino un dispositivo debe convertir el audio de un formato al otro en tiempo real. Ese dispositivo es casi siempre un controlador de borde de sesión (SBC), y la conversión en sí se denomina transcodificación.
Este artículo explica qué hace realmente la transcodificación AMR a G.711 en un SBC, por qué se ubica en la capa del SBC en lugar de dentro del PBX, la diferencia entre transcodificación por hardware y por software, y los escenarios de implementación donde más importa. El objetivo es ofrecer una visión clara y neutral sobre cómo funciona realmente la interoperabilidad de voz móvil a IP en el borde de la red.

Qué hace realmente la transcodificación AMR a G.711

La tarea es sencilla de describir y sorprendentemente exigente de ejecutar. En un lado de la llamada, el SBC recibe paquetes RTP con audio codificado en AMR, muestreado y comprimido para un enlace de radio móvil. En el otro lado debe entregar paquetes RTP con audio G.711, el formato que todo IP-PBX, SIP trunk y gateway PSTN espera. Para conectar ambos, el SBC decodifica el flujo AMR de vuelta a muestras PCM sin procesar, recodifica esas muestras como G.711 (A-law o µ-law, según el destino) y reenvía el resultado con nuevas marcas de tiempo RTP y tipo de payload. La misma conversión se ejecuta en sentido inverso en el camino de retorno.

AMR y G.711 fueron diseñados para mundos diferentes

AMR existe porque el ancho de banda de radio es escaso y las condiciones cambian segundo a segundo. AMR-NB comprime voz de 8 kHz hasta tan solo 4.75 kbps; AMR-WB eleva la frecuencia de muestreo a 16 kHz para una calidad notablemente mejor, pero sigue comprimiendo de forma agresiva. G.711, en cambio, fue diseñado en la década de 1970 para la telefonía fija, donde el ancho de banda era económico y la latencia debía ser cercana a cero. Aplica una compresión logarítmica simple a voz de 8 kHz y produce un flujo constante de 64 kbps. Los dos códecs no son intercambiables, y ningún IP-PBX va a empezar a hablar AMR de repente.

Dónde debe ubicarse la conversión

El PBX y el núcleo móvil son lugares inadecuados para transcodificar. Pedir a un PBX que decodifique AMR de forma nativa obliga a que cada licencia de terminal incluya una pila de códec móvil, cosa que la mayoría no hace. Pedir al núcleo móvil que emita G.711 anula toda la razón por la que los móviles usan AMR en primer lugar. Colocar la transcodificación en el SBC mantiene ambos lados limpios: cada red habla su códec nativo hasta el borde, y la conversión ocurre una sola vez, en la frontera, donde el operador ya controla la señalización y los medios.

Por qué un SBC es el lugar correcto para transcodificar

Tres propiedades de la arquitectura SBC lo convierten en el punto natural de transcodificación. La primera es el control de medios por tramo. Dado que un SBC termina RTP en cada lado y lo conecta con control B2BUA completo, puede aplicar diferentes códecs, tamaños de paquete y tratamientos DTMF en cada tramo de forma independiente. La segunda es la reescritura de SDP. El SBC ve ambos INVITE y puede reescribir la lista de códecs que cada lado anuncia, indicando a la red móvil “admito AMR” mientras le dice al PBX “admito G.711”, y conectando los medios reales en el medio. La tercera es la política. La elección de códec rara vez es solo una preferencia técnica; está determinada por contratos con operadores, conteos de licencias y objetivos de calidad. Incorporar esas políticas en una configuración por NAP en el SBC las mantiene visibles y auditables.

El intercambio SDP

Cuando una llamada originada en un móvil llega al SBC, el INVITE entrante normalmente anuncia AMR-WB como códec preferido, con AMR-NB y posiblemente G.711 como alternativas. El INVITE saliente que el SBC envía al IP-PBX generalmente ofrece solo G.711, porque es lo que el PBX espera. El SBC acepta AMR en el tramo entrante, acepta G.711 en el tramo saliente y transcodifica entre ambos. Como se define en RFC 4566, el cuerpo SDP es lo que hace posible esta mediación de códec sin que ninguno de los terminales sepa que el otro existe.

Re-INVITE y cambios de códec a mitad de llamada

Las redes móviles ocasionalmente renegocian códecs a mitad de llamada, por ejemplo cuando un terminal se mueve entre celdas con diferentes condiciones de radio. Un SBC con arquitectura B2BUA absorbe el re-INVITE resultante en el tramo móvil sin perturbar el tramo del PBX, lo que mantiene la llamada estable desde la perspectiva de la empresa.

Transcodificación por hardware vs. por software

No todos los códecs cuestan lo mismo de transcodificar. G.711 es esencialmente una tabla de búsqueda; convertir entre A-law y µ-law, o entre G.711 y PCM sin procesar, es lo suficientemente económico como para que cualquier servidor x86 moderno lo haga por software para cientos de llamadas concurrentes. AMR es otra historia. AMR-NB y AMR-WB utilizan codificación predictiva lineal con múltiples tasas de bits adaptativas, y el costo de CPU por canal hace que la transcodificación puramente por software sea impracticable a escala de operador.

Por qué la transcodificación AMR necesita DSP hoy

Los DSP de hardware están diseñados específicamente para las operaciones matemáticas que AMR requiere. Un solo appliance DSP de 1U puede ofrecer miles de sesiones concurrentes de transcodificación AMR a G.711 con latencia consistente, mientras que la misma carga de trabajo en núcleos de CPU convencionales consumiría un orden de magnitud más de silicio y produciría un jitter menos predecible. Para cualquier implementación a escala significativa, incluyendo agregación móvil, transferencia VoLTE y voz empresarial gestionada con salida móvil, la transcodificación acelerada por hardware es la opción práctica por defecto.

Cuándo la transcodificación por software es suficiente

La transcodificación por software dentro del SBC maneja la conversión de G.711 µ-law a A-law de forma nativa, lo que cubre el caso de interoperabilidad más común entre Norteamérica y Europa. También maneja la conversión de RTP a SRTP y los cambios de paquetización. El punto en el que una implementación pasa de “el software es suficiente” a “necesita un DSP” es el momento en que un códec complejo como AMR entra en escena.

Alineación de frecuencia de muestreo

AMR-WB muestrea a 16 kHz, G.711 a 8 kHz. La transcodificación debe reducir la frecuencia de muestreo en la salida hacia G.711 y aumentarla en el camino de retorno. La reducción es directa; el aumento no puede recuperar el detalle que AMR-NB o G.711 nunca transportaron en primer lugar, razón por la cual un tramo de banda ancha a banda estrecha suena notablemente más opaco que el lado móvil original. No existe ningún truco del SBC que solucione esto; es una propiedad del códec de destino.

Escenarios de implementación comunes

Operador móvil a IP-PBX o SIP trunk

El caso clásico: un operador móvil transfiere una llamada a un IP-PBX empresarial o a un revendedor de SIP trunks. AMR-WB en el tramo móvil, G.711 en el tramo empresarial, transcodificación en el SBC. Esta es la implementación que la mayoría de los operadores y MSP encuentran primero, y escala linealmente con el tráfico concurrente originado en móviles.

Transferencia de VoLTE a voz heredada

Una llamada VoLTE realizada desde un terminal 4G llega como AMR-WB al borde del IMS, y desde allí debe aterrizar en algún punto de la PSTN más amplia. Si el siguiente salto es un gateway TDM o un SIP trunk heredado, el SBC se ubica entre el núcleo IMS y el gateway, transcodificando AMR-WB a G.711 para que el resto de la red nunca vea el códec de banda ancha.

WebRTC y conexión con Teams

Los terminales WebRTC usan Opus, Microsoft Teams usa G.722, y los móviles usan AMR. Un SBC que conecta plataformas UCaaS con operadores móviles normalmente necesita un plano de transcodificación que maneje los tres, con G.711 como códec intermedio común para la entrega PSTN posterior.

DTMF junto con voz

El mismo hardware que realiza la conversión AMR a G.711 también maneja la traducción de DTMF RFC 2833 a inband en el mismo plano de medios. Ejecutar ambos en un solo plano de transcodificación simplifica el dimensionamiento y las licencias en lugar de distribuir el trabajo entre múltiples appliances.

Consideraciones de calidad de voz

Cada paso de transcodificación tiene un costo, tanto en latencia como en calidad percibida. El impacto de latencia por tramo es pequeño, normalmente unos pocos milisegundos cuando los DSP realizan el trabajo, pero es acumulativo entre saltos, y en una ruta con dos puntos de transcodificación el retardo acumulado comienza a afectar el eco y el ritmo de la conversación. El Mean Opinion Score (MOS) también se degrada cada vez que la voz se decodifica y recodifica, con la caída más pronunciada en conversiones de banda ancha a banda estrecha donde la información se pierde genuinamente. Dos directrices prácticas se mantienen: minimizar la cantidad de saltos de transcodificación en cualquier ruta dada y preferir el códec de mayor calidad que la red de destino pueda admitir. Si el tramo del PBX admite G.711 a 64 kbps completos, no introduzca G.729 solo para ahorrar ancho de banda en un tramo que no lo necesita.

Preguntas frecuentes

Conclusión

La transcodificación AMR a G.711 es la infraestructura invisible que mantiene la comunicación entre la voz móvil y la voz IP. Las redes móviles seguirán enviando AMR mientras la radio celular siga siendo limitada en ancho de banda, y los IP-PBX seguirán demandando G.711 mientras la PSTN más amplia lo haga. El SBC es el único lugar en la ruta con el control de medios por tramo, la visibilidad SDP y los mecanismos de política para mediar esa brecha de forma limpia, y para cargas de trabajo AMR en producción, la transcodificación acelerada por hardware es lo que realmente entrega el rendimiento y la consistencia que el caso de uso requiere. El dimensionamiento, la política de códec y los objetivos de calidad son decisiones que el arquitecto de red posee; el SBC y su plano de transcodificación son la forma en que esas decisiones se hacen realidad en la red.