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

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.
![]()
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 | Sí | No |
| Soporte de VAD | No (passthrough) | No (solo PLC) | Sí (G.729b) | Sí (DTX) | Sí |
| Seguro para fax | Sí (con passthrough) | No | No | No | No |
| DTMF en banda | Sí | 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.