En este artículo pretendo explicar algunos conceptos sobre los codecs de audio que podemos usar en VoIP y aclarar cuál es el que conviene usar en distintos escenarios.

Para empezar debemos tener claro que es un códec y cuál es su función dentro de una llamada VoIP. audio_wave

Simplificando, un códec se encarga de muestrear y comprimir la señal analógica de voz para transmitirla de manera digital y descodificarla en el otro extremo para ser reproducida. En este proceso cada códec tiene distintas características que lo hacen válido para ciertos entornos. Entendiendo que a mayor calidad de audio, es decir, mayor tamaño de muestreo, también aumenta el consumo de ancho de banda que necesitamos para transmitir la conversación.

Vamos a ver uno por uno los cinco codecs más usados en VoIP.

G711, llamado generalmente ulaw (Japón y EEUU)  o alaw (Europa) atendiendo a al método de compresión antes de codificar la señal. Liberado en 1972. Este códec no tiene compresión a nivel de datos y junto su alta tasa de muestreo hace que sea un códec de extraordinaria calidad pero con una tasa de trasferencia de datos muy alta.

G722, conocido por ser una evolución de G711, se considera como un códec HD por la gran calidad de audio que ofrece. Existen otras dos versiones, G722.1 y G722.2, no son evoluciones del primero, si no versiones totalmente nuevas. De hecho G722.2 haciendo uso de la tecnología AMR – WB es capaz de adaptarse a las condiciones de la red de 6.6 a 23.85 kbps. Se suele usar para sistemas de multiconferencia.

GSM, un viejo conocido. Con un bitrate de 13Kbits/s y una calidad aceptable, ha sido una buena elección durante años en los softphones freeware que no disponen de licencia para otro códec y en escenarios con un ancho de banda limitado.

G729, el más extendido en VoIP, se trata de un códec que guarda una buena relación entre calidad y requerimiento de ancho de banda. Con este códec podríamos tener 8 conversaciones más que si estuviésemos usando G711 con el mismo consumo de ancho de banda. No me voy a meter en el jardín del licenciamiento, solo decir que, en Europa no es necesario pagar licencia por su uso y podemos conseguirlo de manera gratuita para muchas de las arquitecturas de procesador actuales.

Opus, uno de los codecs más novedosos y que en mi opinión el mejor. Capaz de adaptarse predictivamente a las condiciones de nuestra red, y dando una excelente calidad si nuestra red tiene capacidad para ello y seguir funcionando en la peor situación. Desarrollado por la IETF, lanzado el 12 de diciembre de 2012 bajo licencia BSD, lo que nos permite usarlo sin tener que pagar por ello. Por ejemplo en Vozelia ofrecen este codec tanto en su PBX (Centralita Virtual) como en sus cuentas de sip trunking.

Comparativa de codecs

CodecPublicaciónBitrateAncho de banda (Ethernet)
G711197264 kb/s87,2 Kbps
G722198864 kb/s87.2 Kbps
G72919968 kb/s31,2 kbps
Opus20126 kb/s a 510 kb/s 8 Kbps - 128 Kbps
GSM199213 kb/s28.63 Kbps

Vamos a comprobar cuantas llamadas podría tener activas una Raspberry Pi con Asterisk sin que el servicio tuviese pérdida de calidad.pi_asterisk

Requisitos:

  • Rasberry Pi con Raspbian.
  • Una maquina donde instalar SIPp.

En mi caso he instalado Asterisk desde los repositorios de debian. Con Raspbian 8.0 ( Conocer vuestra versión de Raspbian: “cat /etc/issue” ) debería instalaros Asterisk 11.13.1.

sudo apt-get install asterisk

En la configuración inicial de Asterisk hay un fallo, el el fichero /etc/asterisk/manager.conf realiza un include de todos los .conf que haya en /etc/asterisk/manager.d/

; #include "manager.d/*.conf"

 

Al final del fichero /etc/asterisk/sip.conf ponéis esto:

[sipp]
type=friend
context=sipp
host=dynamic
port=6000
user=sipp
canreinvite=no
disallow=all
allow=alaw
allow=ulaw

[100]
type=friend
context=sipp
host=dynamic
user=100
secret=<pass>
disallow=all
allow=ulaw

[101]
type=friend
context=sipp
host=dynamic
user=101
secret=<pass>
disallow=all
allow=ulaw

En el fichero /etc/asterisk/extensions.conf, creáis el contexto [sipp] para que nuestras extensiones puedan usarlo. Aquí incluimos al final del fichero:

[sipp]
exten => 1001,1,Answer
exten => 1001,n,SetMusicOnHold(default)
exten => 1001,n,WaitMusicOnHold(20)
exten => 1001,n,Hangup
exten => 1002,1,Answer
exten => 1002,n,Goto(demo,s,1)
exten => 1002,n,Hangup
exten => 100,1,Dial(SIP/100)
exten => 100,n,Hangup
exten => 101,1,Dial(SIP/101)
exten => 101,n,Hangup

Una vez introducidos estos cambios accedemos a la consola de Asterisk.

sudo asterisk –rvvvvvv

Ejecutamos “module reload”, veremos que el sistema recarga toda la configuración, no debe haber errores.

Ahora viene la parte para instalar SIPp. Mi máquina de pruebas para SIPp es una Ubuntu 16.0.4, podemos instalar SIPp directamente desde los repositorios, instalará la versión 3.2.

sudo apt-get install sip-tester

Donde hayamos instalado SIPp lanzamos el siguiente comando:
sipp –sn uac –d 10000 –s 1002 <ip host asterisk> -l 5 –mp 5606

-sn uac Escenario por defecto de SIPp
-d 10000 Tiempo de llamada en milisegundos
-s 1002 Usuario al que vamos a llamar en el otro extremo.
-l 5 Mantener 5 llamadas activas.
-mp 5606 Indicamos donde queremos que nos envíe el RTP de vuelta.

Con esto conseguimos mantener 5 conversaciones activas, de 10 segundos cada una y simulando audio en ambos sentidos. Así conseguiremos un escenario lo más próximo a llamadas reales.

Yo he mantenido dos SSH hacía mi máquina con Asterisk, un terminal con htop para ver los recursos en la Raspberry y otro con la consola de Asterisk para ver la salida.

En una segunda fase, vamos a realizar una llamada real entre dos extensiones para comprobar la calidad de la llamada. Aquí es donde comprobaremos fehacientemente si nuestra pequeña Raspberry está teniendo problemas para mover tantas llamadas.

Para ello, yo he configurado la extensión 100 y 101 que anteriormente hemos configurado en el sip.conf.

Con dos extensiones con el mismo códec (ulaw) hemos mantenido 40 llamadas activas sin que la conversación se viese afectada. Es un valor muy bueno teniendo en cuenta la potencia.

La cosa ha cambiado mucho cuando hemos lanzado una llamada entre ambas extensiones pero cada una con un códec (gsm-ulaw), hemos podido mantener unas 10 llamadas simultaneas.

Conclusiones:
Sin transcoding y sin usar funciones extra de Asterisk podríamos lanzar un numero aceptable de llamadas. Si todas nuestras llamadas van a tener transcoding no creo que se puedan mantener mas de 2 o 3 llamadas simultaneas.

Creo que podríamos mejorar el rendimiento dándole prioridad al proceso Asterisk y eliminando módulos de la configuración del mismo.

Hasta la próxima.