Guía de códecs VoIP: G.711, G.722, G.729, Opus, AMR

Cinco haces de luz paralelos que representan los códecs VoIP G.711, G.722, G.729, Opus y AMR, cada uno con un color y grosor distintos que ilustran las diferencias en ancho de banda y tasa de bits a lo largo del espectro de códecs

Toda llamada VoIP viaja sobre un códec. Cinco de ellos transportan la gran mayoría del tráfico de voz en el planeta, y cada uno fue diseñado en torno a las limitaciones de internet en el momento de su creación. G.711 surgió de la telefonía digital de línea fija y necesitaba caber en módems de 56k. G.722 trajo audio de banda ancha a los teléfonos IP empresariales y es lo que la industria comercializa como HD Voice en el segmento de teléfonos de escritorio. G.729 fue construido para comprimir la voz a través de internet por dial-up. Opus llegó después de 2010 y fue diseñado para un mundo con internet de fibra y capacidades potentes de codificación y decodificación, escalando desde chat de bajo ancho de banda hasta streaming con calidad de estudio. AMR y EVRC son las familias de códecs que las redes móviles estandarizaron, primero para 2G y 3G y ahora para VoLTE.

Esta es una guía panorámica, no una comparación directa. El objetivo es dar a un arquitecto de red, MSP o proveedor de servicios el mapa mental necesario para elegir un códec en cada tramo de una red real: cuál encaja en cada punto, qué compromisos conlleva cada uno, cómo Opus cambió el estándar predeterminado y cómo un SBC arbitra cuando los dos extremos de una llamada no pueden ponerse de acuerdo. Para la comparación detallada entre G.711 y G.729, consulte el artículo dedicado G.711 vs G.729. Para conocer la mecánica de conversión entre códecs en una llamada en vivo, el artículo Transcodificación SBC de AMR a G.711 profundiza en el plano de transcodificación.

Terminos y conceptos clave
Un glosario de referencia rapida para los terminos utilizados en este articulo.
Answer-Seizure Rate (ASR)Un indicador clave de rendimiento utilizado por operadores de telecomunicaciones y proveedores VoIP para medir la eficiencia y calidad general de su infraestructura de enrutamiento de llamadas y de red.
Tasa de bitsLa cantidad de bits comprimidos por segundo que produce el códec para un canal de voz, antes de agregar cualquier encabezado de red. G.711 es fijo en 64 kbps; Opus puede variar de 6 kbps a 510 kbps en la misma llamada.
CódecEl algoritmo que codifica muestras de voz sin procesar en un flujo de bits comprimido para transportarlo a través de una red IP y las decodifica en el extremo receptor. Controla la tasa de bits, la calidad de audio, la latencia y el costo de CPU.
Negociación de códecEl intercambio SDP en el que dos endpoints anuncian los códecs soportados en orden de prioridad y convergen en uno común. Cuando las listas ofrecidas no se superponen, el SBC debe transcodificar o la llamada falla con 488 Not Acceptable Here.
FEC (Forward Error Correction)Datos redundantes incluidos en paquetes adyacentes para que un paquete perdido pueda reconstruirse sin necesidad de retransmisión. Opus tiene FEC integrado; G.711 y G.729 no.
MOS (Mean Opinion Score)Una puntuación perceptual de calidad del habla de 1 a 5. G.711 se sitúa alrededor de 4.2, G.722 alrededor de 4.1, G.729 alrededor de 3.9, AMR-NB alrededor de 3.8, AMR-WB alrededor de 4.1 y Opus alcanza 4.5 en modo de banda ancha.
Banda estrecha, banda ancha, super banda ancha, banda completaLos cuatro niveles de ancho de banda de audio utilizados por los códecs modernos. G.711 y G.729 son de banda estrecha; G.722 y AMR-WB son de banda ancha; Opus escala a través de los cuatro, incluyendo banda completa estéreo. “HD Audio” se refiere a banda ancha.
VBR (Variable Bit Rate)Un modo de códec que ajusta la tasa de bits cuadro por cuadro según la complejidad del audio. Opus y AMR soportan VBR; G.711 y G.729 tienen tasa de bits constante.
Modulación por impulsos codificados (PCM)El esquema de codificación que convierte ondas sonoras analógicas en datos digitales discretos muestreando repetidamente la amplitud de la onda. PCM es el formato sin comprimir desde el cual los códecs codifican y hacia el cual decodifican.
ptime (tiempo de paquetización)La duración de audio contenida en un paquete RTP, típicamente 20, 30 o 40 ms. Se considera que 20 ms es “tiempo real” y cualquier valor por encima de este nivel es perceptible para el usuario. Un ptime mayor reduce la sobrecarga de encabezados a costa de perder más audio por cada paquete descartado.
Tasa de muestreoLa cantidad de muestras de audio tomadas por segundo del habla, medida en kHz. Un muestreo de 8 kHz produce audio de banda estrecha limitado a aproximadamente 3.4 kHz, 16 kHz produce banda ancha, 32 kHz super banda ancha y 48 kHz banda completa.
TranscodificaciónLa conversión en tiempo real de un flujo de audio de un códec a otro. El SBC decodifica el medio entrante y luego lo recodifica en el códec de destino para el otro tramo de la llamada.
VAD (Voice Activity Detection)Una función del códec que deja de enviar paquetes durante los períodos de silencio cuando no hay actividad de voz en una llamada conectada. Útil en enlaces con restricciones de ancho de banda y desactivada deliberadamente para intercambios de datos, incluyendo fax y algunos IVR.
VoLTEVoice over LTE, el estándar de voz móvil 4G que funciona sobre IMS. El códec de audio predeterminado es AMR-WB, con AMR-NB como respaldo. Aquí es donde se origina la mayor parte del tráfico AMR actual.

El panorama de los códecs

Antes de compararlos, conviene entender para qué fue diseñado cada códec. Los cinco fueron creados en décadas diferentes para redes diferentes, y las fortalezas de cada uno aún se remontan a su contexto de diseño original.

G.711 es el códec sobre el que funciona la PSTN. Estandarizado por la ITU-T en 1972, muestrea el habla a 8 kHz y aplica una compresión logarítmica simple (A-law en la mayor parte del mundo, µ-law en América del Norte y Japón) para producir un flujo constante de 64 kbps. El trabajo de codificación y decodificación es trivial, la calidad de voz es esencialmente la que se obtiene de una llamada telefónica por cable, y el códec transporta tonos de fax y DTMF en banda sin problemas. Prácticamente todos los SIP trunk, IP-PBX y puntos de interconexión de operadores soportan G.711 de forma nativa, razón por la cual sigue siendo la lingua franca de VoIP cuarenta años después de su creación.

G.722 es el códec de banda ancha que el mundo de la voz empresarial adoptó para HD Audio. Estandarizado por la ITU-T en 1988, muestrea a 16 kHz y utiliza ADPCM de sub-banda para entregar habla de banda ancha (50 Hz a 7 kHz) a 48, 56 o 64 kbps, con la mayoría de las implementaciones funcionando en modo de 64 kbps. El costo de CPU es trivial, el códec es libre de regalías, y prácticamente todos los teléfonos IP de gama empresarial de Polycom, Cisco, Yealink, Snom y Mitel vienen con G.722 habilitado por defecto. G.722 es lo que la industria denomina HD Voice en el segmento de teléfonos de escritorio y SIP empresarial. No es seguro para fax y no transporta DTMF en banda, pero en un SIP trunk limpio entre dos teléfonos HD de escritorio, es la forma más sencilla de obtener audio de banda ancha sin cambiar nada más en la infraestructura.

G.729 es el códec que la telefonía VoIP corporativa utilizó en las décadas de 1990 y 2000. Estandarizado en 1996, cuando los enlaces WAN eran estrechos y costosos, muestrea a los mismos 8 kHz que G.711 pero comprime cada trama de 10 ms a 80 bits usando CS-ACELP, un modelo predictivo del tracto vocal que entrega 8 kbps. La matemática está optimizada para voz humana limpia y no sobrevive a tonos de módem de fax, música en espera ni DTMF en banda. Las patentes de G.729 comenzaron a expirar en 2017 y el códec es ahora efectivamente libre de regalías, aunque los proveedores comerciales de PBX a menudo siguen cobrando licencias por canal basándose en el modelo de ingresos heredado.

Opus es el códec de la era moderna de internet. Estandarizado por la IETF en 2012 como RFC 6716, combina dos algoritmos en un solo códec: SILK (el códec utilizado por Skype) para habla a tasas de bits bajas a medias, y CELT para música y audio de alta tasa de bits. Opus escala desde 6 kbps en modo mono de banda estrecha hasta 510 kbps en estéreo de banda completa dentro de una sola sesión negociada, incluye FEC y ocultación de pérdida de paquetes, y está libre de patentes bajo una licencia permisiva. WebRTC hizo de Opus un requisito obligatorio, Microsoft Teams lo utiliza en el lado del cliente, y la mayoría de las plataformas modernas de UCaaS y CPaaS lo negocian por defecto. Opus requiere más capacidad de cómputo que los códecs anteriores, razón por la cual la telefonía móvil y las industrias de endpoints más pequeños han sido más lentas en adoptarlo.

AMR (Adaptive Multi-Rate) es el códec que las redes móviles estandarizaron. Se utilizan dos variantes principales: AMR-NB con muestreo a 8 kHz y de 4.75 a 12.2 kbps, introducido originalmente para GSM, y AMR-WB con muestreo a 16 kHz y hasta 23.85 kbps, obligatorio para VoLTE en la mayoría de los operadores. AMR codifica el habla en tramas de 20 ms con adaptación de tasa VBR, por lo que un enlace de radio que se degrada puede bajar a la tasa de bits más baja sin renegociar la llamada. AMR rara vez aparece en SIP trunk empresariales porque el tráfico de móvil a IP casi siempre se transcodifica a G.711 en la pasarela de medios del operador móvil o en un SBC aguas abajo.

Matriz de comparación de un vistazo

Los cinco códecs difieren en aproximadamente diez dimensiones que importan en producción. La tabla a continuación los coloca lado a lado para que las diferencias sean visibles en una sola vista. Los números son valores predeterminados típicos; cada códec tiene modos y anexos que modifican algunos de los valores.

Dimensión G.711 G.722 G.729 Opus AMR
Tasa de muestreo 8 kHz 16 kHz 8 kHz 8 / 12 / 16 / 24 / 48 kHz 8 kHz (NB), 16 kHz (WB)
Ancho de banda de audio Banda estrecha Banda ancha Banda estrecha Banda estrecha a banda completa Banda estrecha (NB), banda ancha (WB)
Tasa de bits (payload) 64 kbps fijo 48 / 56 / 64 kbps fijo 8 kbps fijo 6 a 510 kbps VBR 4.75 a 23.85 kbps VBR
MOS típico 4.2 4.1 (banda ancha) 3.9 4.5 (banda ancha) 3.8 (NB), 4.1 (WB)
FEC integrado No No No No
Soporte de VAD No (passthrough) No (solo PLC) Sí (G.729b) Sí (DTX)
Seguro para fax Sí (con passthrough) No No No No
DTMF en banda No No No No
Costo de CPU Trivial Trivial Moderado Moderado a alto Moderado
Estado de licencia Libre de regalías Libre de regalías Libre de regalías (desde 2017) Libre de regalías Con regalías (3GPP)
Caso de uso principal PSTN, SIP trunk, fax Teléfonos HD de escritorio, SIP empresarial de banda ancha WAN con restricción de ancho de banda WebRTC, Teams, UCaaS, chat de voz Móvil, VoLTE

Tres aspectos destacan en la matriz. Primero, solo G.711 transporta fax y DTMF en banda de manera confiable; todos los demás códecs de esta lista requieren DTMF fuera de banda (RFC 4733) y T.38 para fax. Segundo, G.722 entrega audio de banda ancha al mismo ancho de banda de 64 kbps que G.711, razón por la cual los teléfonos HD de escritorio lo utilizan por defecto en SIP empresarial sin renegociar presupuestos de ancho de banda. Tercero, Opus es el único códec que abarca todo el rango de ancho de banda de audio en una sola sesión negociada (a costa de un mayor rendimiento computacional), lo que lo hace funcional tanto para una llamada de voz con restricciones como para una aplicación de streaming de música sin cambiar de códec.

Banda ancha vs banda estrecha como decisión de primer nivel

La dimensión de la tasa de muestreo importa más que la dimensión de la tasa de bits en la mayoría de las implementaciones modernas, y es la que se pasa por alto con mayor frecuencia. G.711 y G.729 muestrean a 8 kHz, lo que limita el audio transportado a aproximadamente 3.4 kHz. Ese es el ancho de banda de una llamada PSTN por cable y la razón por la que el audio telefónico tradicional suena ligeramente amortiguado en comparación con una conversación en persona. G.722, AMR-WB y Opus operan a 16 kHz o más, duplicando el ancho de banda de audio transportado a aproximadamente 7 kHz. La diferencia es inmediatamente audible: las consonantes son más nítidas, las sibilantes sobreviven intactas y la llamada suena más cercana a una conversación cara a cara. En el lado SIP empresarial, G.722 ha sido el caballo de batalla de banda ancha durante más de una década; en el lado de la nube, Opus ha asumido el mismo rol.

Esto importa en tres contextos. El primero es cualquier llamada que conecta Microsoft Teams o WebRTC con un operador tradicional. Tanto Teams como los endpoints de navegador pueden negociar audio de banda ancha en su lado; en el momento en que la llamada llega a un SIP trunk G.711, la señal de banda ancha se submuestrea y el oyente en el lado de la nube escucha banda estrecha. El segundo son los centros de contacto que ejecutan analítica de voz. La precisión del ASR (reconocimiento de voz) mejora notablemente cuando el códec es de banda ancha, por lo que las grabaciones de llamadas en Opus o AMR-WB son más fáciles de transcribir de voz a texto que las mismas llamadas grabadas después de un salto G.729. El tercero son las conferencias ejecutivas y los servicios de HD Voice, donde la experiencia de banda ancha es el producto en sí.

La implicación práctica para la política de códecs: una implementación que ya cuenta con endpoints capaces de banda ancha pierde la experiencia de banda ancha en el momento en que un códec de banda estrecha entra en cualquier tramo de la ruta. La solución no siempre es actualizar cada trunk a un códec de banda ancha, sino saber exactamente qué tramo está reduciendo el ancho de banda y decidir si la pérdida es aceptable para ese segmento.

Selección de códec por caso de uso

Elegir un códec a nivel de plataforma rara vez produce la respuesta correcta. La decisión corresponde a nivel de grupo de trunk, a veces a nivel de llamada individual, y el códec correcto depende enteramente de lo que la llamada está haciendo y qué red atraviesa. Los patrones a continuación cubren los casos que surgen con mayor frecuencia en redes de voz en producción.

Un SIP trunk greenfield entre dos endpoints modernos, donde el ancho de banda no es la restricción principal, debería utilizar G.711 por defecto. El códec tiene soporte universal, está libre de licencias, es seguro para fax con las condiciones de passthrough cumplidas, y tiene un costo de CPU trivial. Si ambos endpoints soportan Opus y la plataforma es completamente greenfield sin requisito de passthrough de fax o DTMF, Opus es un mejor valor predeterminado para el mismo caso de uso porque escala a banda ancha cuando la red puede transportarlo.

Un segmento WAN con restricciones, típicamente una sucursal en un enlace compartido de 1 a 4 Mbps donde cada 50 kbps de margen importa, sigue siendo un lugar legítimo para G.729. El ahorro de ancho de banda es real, la caída de calidad percibida es manejable, y los compromisos (fax sobre T.38, RFC 4733 para DTMF) son bien comprendidos. En una implementación greenfield con equipos modernos y capacidades de fibra modernas, Opus a 16 a 24 kbps generalmente supera a G.729 en calidad con un ancho de banda similar en el cable, con el beneficio adicional de FEC y recuperación elegante ante pérdida de paquetes.

Una ruta de móvil a IP casi siempre involucra AMR en el lado móvil y G.711 en el lado IP. El límite de transcodificación se encuentra en la pasarela de medios del operador móvil o en el SBC empresarial, dependiendo del contrato de interconexión. Las rutas VoLTE a PSTN, centro de contacto móvil y roaming de voz caen dentro de este patrón. La capacidad de DSP por hardware para realizar transcodificación AMR de forma limpia a escala es el cuello de botella práctico, que es exactamente lo que TSBC-HW-TRANS existe para proveer.

Una ruta de llamada con fax es la única situación donde la elección de códec no es negociable. CS-ACELP, SILK y AMR destruyen los tonos de módem T.30. La llamada debe permanecer en G.711 de extremo a extremo con las condiciones de passthrough cumplidas (cancelación de eco deshabilitada, VAD deshabilitado, pérdida de paquetes cercana a cero) o cambiar a relay T.38 en el SBC. El artículo Fax sobre IP y T.38 cubre la mecánica del relay en detalle.

Un centro de contacto con grabación, analítica de ventas o puntuación basada en ASR se beneficia mejor de Opus en cualquier tramo que la plataforma soporte, y G.711 en los demás. La transcodificación en tándem afecta la precisión del ASR de la misma forma en que afecta la percepción humana, por lo que el objetivo es minimizar la cantidad de conversiones de códec en la ruta grabada. La misma lógica aplica a las implementaciones de voice AI: cada salto de transcodificación agrega latencia y degrada la señal STT, por lo que la política de códec se ajusta a las tolerancias del stack de AI.

Por qué Opus está transformando la configuración predeterminada

Opus es el primer códec que desafía seriamente a G.722 como el códec de banda ancha predeterminado para nuevas implementaciones VoIP, y las razones son estructurales, no incrementales. G.711 no es realmente el competidor aquí. Mantiene el dominio de banda estrecha, fax y el frente orientado a operadores, y no va a desaparecer. La competencia está en la capa de banda ancha, donde G.722 ha sido el incumbente SIP empresarial durante más de una década. Opus fue diseñado por la IETF para resolver los problemas que WebRTC encontró al intentar estandarizar voz en tiempo real en un navegador, y las mismas decisiones de diseño le dan tres ventajas sobre G.722 en implementaciones greenfield.

La primera es el rango. Opus negocia una sola sesión que puede transportar desde un canal de voz de banda estrecha a 6 kbps hasta un flujo de música estéreo de banda completa a 510 kbps, y puede cambiar entre modos durante la llamada sin renegociar SDP. G.722, en cambio, funciona a tres tasas de bits fijas (48, 56, 64 kbps) con una sola tasa de muestreo de 16 kHz. Una llamada en Opus que necesita reducir a una tasa de bits baja cuando la red se degrada puede hacerlo sin un re-INVITE; una llamada G.722 a 64 kbps permanece a 64 kbps hasta que la llamada termina.

La segunda es la resiliencia integrada. Opus incluye Forward Error Correction en paquetes adyacentes, de modo que un paquete perdido puede reconstruirse a partir del siguiente en lugar de retransmitirse o ocultarse con silencio. G.722 solo tiene ocultación básica de pérdida de paquetes, sin FEC, sin DTX. En una red que pierde del 2 al 3 por ciento de sus paquetes, Opus sigue siendo inteligible donde G.722 comienza a desarrollar artefactos audibles y donde G.729 se quiebra por completo.

La tercera es la ubicuidad en endpoints modernos. WebRTC hizo de Opus un requisito obligatorio, todos los navegadores lo incluyen, Microsoft Teams lo utiliza en el lado del cliente, Zoom usa una variante de Opus, y Discord, Slack huddles, Google Meet y prácticamente todas las aplicaciones de voz y video para consumidores tienen Opus en su lista de códecs. G.722 esencialmente nunca ha salido del mundo de los teléfonos IP empresariales. El resultado es que Opus es el códec de banda ancha natural para cualquier implementación cuyos endpoints incluyan navegadores, softphones o usuarios de UCaaS junto con teléfonos de escritorio tradicionales, que hoy en día son la mayoría.

La razón por la que Opus aún no ha barrido la capa de banda ancha por completo es la interoperabilidad, no la tecnología. Operadores, proveedores de PBX y productos SBC se han construido en torno a G.711, G.722 y G.729 durante décadas; agregar Opus a la lista de códecs ofrecidos por un operador es un cambio contractual y operativo tanto como técnico. G.722 sigue ganando por defecto en un SIP trunk limpio entre dos teléfonos HD de escritorio porque ambos lados ya lo hablan y no se requiere transcodificación. Opus está comenzando a desplazar a G.722 en implementaciones greenfield donde ambos endpoints lo negocian, y en implementaciones híbridas que conectan SIP empresarial con Teams, WebRTC o una plataforma UCaaS. El puente entre el mundo nativo de Opus (navegadores, Teams, UCaaS) y el mundo nativo de G.711 / G.722 (operadores, PBX, teléfonos HD de escritorio, fax) es exactamente donde se ubica el SBC, y la transcodificación de Opus a G.711 es ahora una de las conversiones de códec más comunes en producción. ProSBC soporta transcodificación Opus a través de TSBC-HW-TRANS hoy.

Negociación de códecs entre distintos proveedores

Elegir un códec para cada tramo es una decisión. Lograr que los dos extremos de una llamada realmente utilicen el códec elegido es otra. La negociación de códec ocurre en el cuerpo SDP del SIP INVITE y 200 OK, donde cada lado anuncia sus códecs soportados en orden de prioridad y la llamada converge en la coincidencia de mayor prioridad. Cuando las listas son asimétricas, el SBC tiene tres opciones: reescribir la lista de códecs ofrecida en un tramo para que exista una coincidencia, transcodificar en el medio, o fallar la llamada con 488 Not Acceptable Here.

La primera opción, la reescritura de la lista de códecs SDP, es la más económica. Si un operador de América del Norte ofrece G.711 µ-law primero y el PBX de un cliente europeo prefiere G.711 A-law, el SBC puede reordenar o recortar la lista ofrecida por tramo para que ambos lados vean un códec que aceptan. No se involucra hardware de transcodificación. Así es como funciona la mayoría de la interoperabilidad G.711 A-law a µ-law en producción, y el SBC se comporta de la misma manera para cualquier asimetría de ruta de audio donde los tramos entrantes y salientes no coinciden en el códec preferido.

La segunda opción, la transcodificación, es en lo que todo puente de Opus a G.711 finalmente se convierte. El SBC decodifica el medio entrante a PCM sin comprimir, lo recodifica en el códec de destino y reenvía el resultado con nuevas marcas de tiempo RTP y un nuevo tipo de payload. La transcodificación por software dentro del SBC cubre los casos simples (G.711 A-law a µ-law, conversión de ptime de G.711); la transcodificación por DSP de hardware maneja los códecs complejos a escala de operador. La mecánica del plano de transcodificación, incluyendo cómo un SBC B2BUA maneja el handshake SDP y los flujos de re-INVITE, se cubre en detalle en el artículo Transcodificación SBC de AMR a G.711.

La tercera opción, fallar la llamada, es una decisión de configuración. Algunos operadores prefieren rechazar llamadas que requerirían una conversión de códec no deseada (por razones de costo, calidad o cumplimiento) en lugar de transcodificar silenciosamente. El SBC lo aplica a través de la política de códec por NAP: cada grupo de trunk tiene su propia lista de códecs preferidos, lista de respaldo y bandera de “transcodificar si no hay coincidencia”, todo aplicado en el límite sin que ninguno de los endpoints necesite saber qué está haciendo el otro. Esa política de códec por tramo y por trunk es la unidad operativa de la gestión de códecs en una red real.

El costo de la transcodificación

La transcodificación es la palanca que hace funcionar las redes de códecs mixtos, y conlleva tres costos que deben dimensionarse en la etapa de diseño. Ninguno de ellos es un impedimento, pero ignorarlos produce redes que suenan peor de lo que deberían.

El primer costo es la calidad de voz. Cada salto de transcodificación aplica un viaje de ida y vuelta con pérdida a través de PCM, y el MOS cae en cada conversión. Una ruta única G.711 a Opus a G.711 acumula unas pocas décimas de punto MOS de degradación, y una llamada que cruza dos límites de transcodificación puede terminar por debajo del MOS nominal de cualquiera de los códecs. El objetivo arquitectónico es minimizar la cantidad de conversiones de códec en la ruta enrutada, no optimizar cada tramo de forma aislada.

La tabla a continuación ubica cada códec en el espectro de con pérdida versus sin pérdida y de banda estrecha versus banda completa, para que el panorama de calidad sea visible en una sola vista.

Códec Tipo Ancho de banda
FLAC / PCM Sin pérdida Banda completa
G.711 Con pérdida (leve) Banda estrecha (8 kHz)
G.722 Con pérdida (leve) Banda ancha (16 kHz)
G.729 Con pérdida (agresiva) Banda estrecha
Opus Con pérdida (perceptual) Hasta banda completa

El segundo costo es la latencia. Cada paso de transcodificación agrega aproximadamente 20 ms de procesamiento con buffer de trama por dirección. En un puente de un solo salto esto es invisible; en una ruta que ya se acerca al presupuesto de latencia conversacional (móvil a agente AI, SIP trunk intercontinental, backhaul satelital), un salto de transcodificación adicional puede llevar la conversación a un territorio de retardo perceptible.

El tercer costo es la capacidad de hardware. La transcodificación por software para variantes de G.711 de banda estrecha funciona en CPU commodity a alta densidad. A escala de operador hoy en día, la transcodificación de códecs complejos reside en tarjetas DSP de hardware porque la latencia predecible por canal importa más que el rendimiento máximo. ProSBC se integra con TSBC-HW-TRANS para ese rol, con hasta 2,744 sesiones por enclosure de 1U y apilamiento hasta 30,000 sesiones.

Preguntas frecuentes

¿Cuál de estos cinco códecs ofrece la mejor calidad de voz?

Opus en modo de banda ancha, por un margen claro. Su MOS de alrededor de 4.5 se sitúa por encima del 4.2 de G.711, el 4.1 de G.722 y AMR-WB, el 3.9 de G.729 y el 3.8 de AMR-NB. La limitación es que Opus solo gana cuando ambos endpoints lo negocian y la red lo transporta de extremo a extremo. Una llamada que se conecta a un SIP trunk G.711 cae a banda estrecha independientemente de lo que el endpoint Opus pueda hacer.

¿Por qué Opus rara vez se ve en SIP trunk tradicionales a pesar de ser técnicamente superior?

Dos razones. La primera es el legado: la infraestructura de operadores, las listas contractuales de códecs y los sistemas PBX fueron construidos en torno a G.711 y G.729 mucho antes de que Opus existiera, y agregar Opus a la lista de códecs ofrecidos por un operador es un proyecto operativo, de facturación e interoperabilidad, no un cambio de código. La segunda, y la más interesante, es que el mundo de SIP trunk que quería audio de banda ancha no esperó a que llegara Opus. Se estandarizó en G.722, hace más de una década. G.722 es libre de regalías, viene habilitado por defecto en todos los teléfonos IP de gama empresarial, funciona a los mismos 64 kbps que G.711 (por lo que se ajusta al presupuesto de ancho de banda existente sin renegociación) y no necesita nuevo hardware de transcodificación para interoperar con nada en un SIP trunk empresarial típico. Opus es técnicamente superior, con mejor FEC, un rango completo de ancho de banda y tasas de bits más bajas a la misma calidad, pero esas ventajas no se manifiestan en un SIP trunk limpio entre dos teléfonos HD de escritorio, que es exactamente el escenario para el que G.722 fue diseñado. Opus ha ganado el lado nativo de la nube de la red (navegadores, Teams, UCaaS, CPaaS) porque ese lado no tenía un códec de banda ancha incumbente; el lado SIP empresarial ya lo tenía.

¿AMR es algo que necesito soportar directamente fuera de las redes móviles?

En la mayoría de las redes de voz empresariales, no. Los operadores móviles transcodifican AMR a G.711 en su pasarela de medios antes de entregar la llamada al mundo IP, por lo que el códec AMR nunca llega a un SIP trunk empresarial típico. Las excepciones son los proveedores de servicios que manejan interconexión móvil directamente, los MSP que sirven verticales con alto tráfico móvil, y cualquier implementación que exponga una interfaz SIP directamente hacia VoLTE o un core IMS. Para esos casos de uso, la capacidad de transcodificación AMR-NB y AMR-WB es un elemento real de planificación, y la transcodificación generalmente reside en DSP de hardware hoy en día.

¿Cuándo importa realmente la elección de códec frente a cuándo es operativamente irrelevante?

Importa en el contexto de restricciones de CPU, cuando hay fax o DTMF en la ruta, cuando el pipeline de grabación de llamadas o ASR aguas abajo es sensible a artefactos de compresión, o cuando la llamada cruza una plataforma capaz de banda ancha (Teams, WebRTC) hacia un operador de banda estrecha. Es operativamente irrelevante en una LAN moderna bien aprovisionada o un SIP trunk dedicado que lleva cómodamente la carga de llamadas, donde la diferencia entre 87 kbps y 31 kbps por llamada es invisible.

¿Opus eventualmente reemplazará a G.722, G.729 y AMR como el códec VoIP predeterminado?

Sí, la industria está convergiendo lentamente hacia ese resultado. En el lado de operadores y PSTN, el reemplazo será lento porque el códec está integrado en contratos de interconexión, tarjetas DSP de hardware, términos de licencia de PBX y requisitos de interoperabilidad de fax. El panorama realista a largo plazo son dos códecs predeterminados coexistiendo: Opus en todos los lugares donde una infraestructura moderna lo negocia, G.711 en todos los lugares donde hay una ruta de operador tradicional o de fax involucrada, y un SBC haciendo de puente entre ambos.

Conclusión

Los cinco códecs que cubren casi todo el tráfico VoIP ocupan cada uno un carril definido. G.711 sigue siendo el predeterminado para los tramos de línea fija, con fax y orientados al operador. G.722 es el incumbente de banda ancha en el lado SIP empresarial, especialmente entre teléfonos HD de escritorio donde ambos lados ya lo hablan. G.729 aún gana su lugar en segmentos con restricción de ancho de banda e interconexiones heredadas, con patentes expiradas y licenciamiento simplificado. Opus se ha convertido en el predeterminado del lado nativo de la nube, desde WebRTC hasta Teams y UCaaS móvil, y su flexibilidad, FEC y estatus libre de regalías lo hacen el candidato más fuerte para nuevas implementaciones greenfield con altas capacidades de CPU. AMR transporta el mundo móvil desde terminales 2G hasta VoLTE, pero rara vez aparece en SIP trunk empresariales porque los operadores móviles transcodifican en la pasarela de medios. La pregunta operativa rara vez es en qué códec único estandarizarse, sino cómo establecer la política de códec por tramo, dónde la aplica el SBC y cómo mantener la cantidad de saltos de transcodificación lo más baja que la topología permita.

Establezca la política de códec por tramo con ProSBC

ProSBC maneja la señalización SIP, el control de medios B2BUA, la negociación de códec por NAP y la reescritura de SDP que permite a un solo SBC conectar G.711, G.722, G.729 y AMR a través de cualquier combinación de operadores, sistemas PBX, interconexiones móviles y plataformas UCaaS. Para la conversión de G.711 A-law a µ-law y la alineación de ptime, ProSBC transcodifica nativamente por software sin necesidad de hardware externo. Para G.729, AMR y el conjunto completo de códecs complejos a escala de operador, ProSBC se integra con TSBC-HW-TRANS, una unidad de transcodificación por hardware que soporta hasta 2,744 sesiones por enclosure de 1U y apilamiento hasta 30,000 sesiones.

ProSBC funciona sobre VMware, KVM, AWS, Azure o bare metal, y se integra con la unidad de transcodificación a través del mismo plano de gestión. La política de códec que usted establece en cada grupo de trunk es lo que su red realmente hace en el cable.

¿Prefiere evaluar por su cuenta primero? Inicie su prueba gratuita de 30 días.