Novena Parte – RTPEngine trasncodificación y grabación de llamadas
En esta parte veremos como sacarle provecho al Proxy media RTPEngine; más en especifico veremos
como configurarlo para que permita la trasncodificación de distintos codecs audio/video de forma que
dispositivos que no comparten codec audio/video puedan comunicarse de todas formas; por ultimo
veremos como realizar la configuración para poder grabar el audio de las llamadas.
Para que estás dos funcionalidades puedan funcionar correctamente, RTPEngine tendrá que estar
SIEMPRE en el medio de las llamadas es decir que todo el flujo media deberá pasar por él, visto
gráficamente:
Flujo Media
DispositivoA RTPEngine DispositivoB
Este tipo de configuración además de la posibilidad de grabar el audio de las llamadas permitirá
también, como veremos el la parte dedicada al monitoreo de Kamailio, enviar las estadísticas del flujo
media a un servidor Homer SIP Capture Server de forma que será posible acceder a todos los datos que
permiten medir la calidad de las llamadas.
Como ha quedado la configuración hasta el momento, en todas las llamadas el flujo audio pasa por
RTPEngine, esto desde que se realizó el cambio en la Séptima parte de este modulo semanal cuando se
ha eliminado esta linea:
if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return;
de la subruta que inicia con en esta linea:
route[NATMANAGE]
activando, de esta forma, RTPEngine para todos los dispositivos, estén o no detrás de una NAT. Antes
de empezar con la nueva configuración, sacamos una copia del archivo de configuración como ha
quedado después de la configuración del cifrado de la señalización SIP:
cp /etc/kamailio/[Link] /etc/kamailio/[Link]
IMPORTANTE: al final del documento encuentran las instrucciones para descargar el archivo
de configuración como va a quedar al terminar esta parte.
Si volvemos a mirar la documentación del modulo RTPEngine, veremos que en la parte dedicada a las
opciones utilizables con las distintas funciones activadas por el modulo aparece:
codec-transcode
1
esta opción permite añadir codec que si no están presentes en el anexo SDP original serán añadidos y al
mismo tiempo en RTPEngine se activará la funcionalidad de transcoding. Para realizar un primer
ejemplo, modificamos este bloque (desde la linea 888):
if(nat_uac_test("8")) {
rtpengine_manage("SIP-source-address replace-origin replace-session-connection");
} else {
rtpengine_manage("replace-origin replace-session-connection");
}
para que quede:
if(nat_uac_test("8")) {
rtpengine_manage("SIP-source-address replace-origin replace-session-connection
codec-transcode-opus codec-transcode-PCMA codec-transcode-PCMU");
} else {
rtpengine_manage("replace-origin replace-session-connection codec-transcode-opus
codec-transcode-PCMA codec-transcode-PCMU");
}
De esta forma, si los codec audio PCMA (alaw), PCMU (ulaw) y OPUS no están presentes en el anexo
SDP original, se añadirán y RTPEngine podrá transcodificar en el caso en que los dos dispositivos no
tengan por lo menos un codec audio/video en común. Guardamos los cambios y reiniciamos Kamailio.
systemctl restart kamailio
Ahora abrimos el Softphone Jitsi y modificamos la extensión configurada, que era la 1002, para que en
Codificación quede solamente el codec audio opus:
Una vez realizado el cambio, abrimos Xlite u otro Softphone con configurados solamente los codec
audio ULAW y ALAW:
2
Vamos al terminal de Linux y abrimos el programa Sngrep:
sngrep
presionamos la tecla F8 y en la pagina Call Flow, si ya no lo hemos hecho, ponemos la siguiente
configuración:
Damos Accept y realizamos una llamada de una extensión a otra. El resultado en Sngrep será:
Del lado de X-Lite se utilizará el codec ALAW y del lado de Jitsi el codec OPUS. Como pueden ver la
IP desde donde llegará el flujo media será la [Link] que es la IP publica de mi servidor de
prueba. La llamada en este caso es desde Xlite hacia Jitsi. En el LOG de RTPEngine:
El codec opus no configurado en Xlite será añadido a la lista de los codec ofrecidos a Jitsi; ALAW y
ULAW no serán añadidos ya que estás presentes en el anexo SDP original:
3
cuando empezará el flujo media RTPEngine empezará a trasncodificar de PCMA a OPUS y viceversa.
Con esta primera prueba hemos averiguado que el sistema funciona.
Otras opciones interesantes que se pueden configurar son:
• codec-strip: elimina el codec indicado de la lista de los codec ofrecidos. Ejemplo: el Softphone
Xlite tiene configurado PCMA y PCMU y en codec-strip se indica codec-strip-PCMA, PCMA
será eliminado de la lista de codec enviados al destinatario y no podrá ser utilizado
• codec-offer: permite ofrecer algunos codec ya presentes en la lista de codec enviados por el
dispositivo. Ejemplo: El Softphone soporta PCMU y PCMA pero con codec-strip-all se quitan
todos los codec y luego con codec offer se vuelve a ofrecer el de nuestro interés, por ejemplo
PCMU
• codec-mask: parecido a codec-strip con la diferencia que los codec enmascarados podrán ser
utilizados para el transcoding y serán enmascarados en la oferta hecha al dispositivo de destino.
La idea es que realicen pruebas de las distintas opciones y reporten los resultados en el foro de esta
semana.
Ahora pasamos a la grabación de las llamadas. Primero miramos si el programa utilizado para esta
tarea esté corriendo:
systemctl status rtpengine-recording
* [Link] - NGCP RtpEngine - RTP Recording Daemon
Loaded: loaded (/etc/systemd/system/[Link]; enabled; vendor preset: disabled)
Active: active (running) since mar 2020-05-05 [Link] -05; 2 weeks 5 days ago
Recordamos que al momento de la compilación del programa, creamos un archivo de configuración:
nano /etc/[Link]
que contiene todos los parámetros utilizados para la grabación:
[rtpengine-recording]
table = 0
output-format = wav
spool-dir = /var/spool/rtpengine
output-dir = /tmp
resample-to = 8000
output-mixed = true
output-single = false
4
lo datos presentes:
• linea 2 – tabla a nivel de Kernel utilizada para la grabación
• linea 3 – formato audio en que se guardarán las grabaciones
• linea 4 – carpeta utilizada para archivos temporales y algunos datos dependiendo del metodo de
grabación utilizado
• linea 5 – carpeta final donde se almacenarán los archivos audio
• linea 6 – frecuencia de muestreo de los archivos audio finales
• linea 7 – se guardará el audio de los dos canales en un único archivo
• linea 8 – no se guardará el audio de los dos canales en dos archivos distintos
Para activar la grabación de las llamadas tenemos disponibles dos métodos distintos; uno indicando una
opción en la función rtpengine_manage, record-call=on, o utilizando una función dedicada activada
por el modulo rtpengine, start_recording. La diferencia entre una y otra es que la primera permite la
entera grabación de la llamada incluyendo los datos de los anexos SDP y de los metadatos que se
pueden indicar en la misma función rtpengine_manage.
La grabación audio de las llamadas se pueden realizar utilizando dos opciones distintas:
• pcap: en este caso el archivo final será en formato PCAP y contendrá todo el flujo media. No
necesita el modulo del Kernel de RTPEngine para funcionar correctamente
• proc: utilizará el modulo del Kernel de RTPEngine que se ha compilado al momento de la
instalación del programa. En este caso se guardará solamente el archivo audio en el formado
indicado en el archivo de configuración que acabamos de mirar
Escoger una opción u otra dependerá del tipo de resultado que necesitamos. En el primer caso (pcap),
al terminar la llamada, encontraremos dos nuevos archivos, uno en la carpeta
/var/spool/rtpengine/metadata/ que contendrá una serie de metadatos relacionados con la llamada;
otro en la carpeta /var/spool/rtpengine/pcaps/ que contendrá el archivo en formato PCAP del flujo
media. En el segundo caso (proc) encontraremos solamente el archivo audio en el formato indicado en
el archivo /etc/[Link]
En este curso se ha optado por utilizar la opción proc. Para que funcione correctamente hay que seguir
estos pasos:
1. asegurarse que el modulo del Kernel de Rtpengine, xt_RTPENGINE, sea cargado correctamente
al iniciar el sistema
2. modificar la configuración de RTPEngine
3. modificar el archivo de configuración de Kamailio.
Para el primer punto, se copia el modulo del Kernel de RTPEngine en la una carpeta de la versión del
Kernel en uso.
IMPORTANTE: Esta Operación ya se realizó en la segunda parte del Primer Modulo semanal;
de todas formas se va a repetir el procedimiento
Para conocer la versión del Kernel en uso:
5
uname -r
3.10.0-1160.31.1.el7.x86_64
Luego:
cp /usr/src/rtpengine/kernel-module/xt_RTPENGINE.ko /usr/lib/modules/3.10.0-1160.25.1.el7.x86_64/extra
Asegurarse que el modulo sea cargado a cada inicio del sistema:
nano /etc/modules-load.d/[Link]
se copia la siguiente linea:
xt_RTPENGINE
se guardan los cambios y se reinicia el sistema:
reboot
Se vuelve a acceder y se averigua si el modulo se ha cargado correctamente:
lsmod | grep xt_RTPENGINE
El resultado debería ser:
xt_RTPENGINE 41537 2
Ahora que tenemos la certeza que el modulo se carga correctamente, pasamos al segundo punto que es
la configuración de RTPEngine. Abrimos el archivo de configuración:
nano /etc/sysconfig/rtpengine
y añadimos las siguientes opciones antes de las comillas finales:
--recording-dir=/var/spool/rtpengine --recording-method=proc --table=0
con la primera opción indicamos la carpeta donde se guardarán las grabaciones antes de ser movidas a
la carpeta /tmp configurada en el archivo /etc/[Link], con la segunda opción
indicamos el método de grabación que se utilizará; en este caso proc; en la ultima opción se indica la
tabla que a nivel de Kernel se utilizará para el proceso de grabación. Se guardan los cambios y se
reinicia RTPEngine:
systemctl restart rtpengine
Ahora se puede pasar al ultimo punto que es la configuración adicional de Kamailio:
6
kacfg
volvemos al bloque donde se utiliza la función rtpengine_manage (desde la linea 888):
if(nat_uac_test("8")) {
rtpengine_manage("SIP-source-address replace-origin replace-session-connection
codec-transcode-opus codec-transcode-PCMA codec-transcode-PCMU");
} else {
rtpengine_manage("replace-origin replace-session-connection codec-transcode-opus
codec-transcode-PCMA codec-transcode-PCMU");
}
y lo modificamos para que quede:
if(nat_uac_test("8")) {
rtpengine_manage("SIP-source-address replace-origin replace-session-connection
codec-transcode-opus codec-transcode-PCMA codec-transcode-PCMU record-call=on");
} else {
rtpengine_manage("replace-origin replace-session-connection codec-transcode-opus
codec-transcode-PCMA codec-transcode-PCMU record-call=on");
}
IMPORTANTE: las dos lineas que inician con rtpengine_manage tienen que estar en el mismo
renglón.
Se guardan los cambios y se reinicia Kamailio:
systemctl restart kamailio
Se abren dos SoftPhone y se realiza una llamada entre los dos. Al terminar la llamada en la carpeta /tmp
aparecerá el archivo de la grabación de la llamada en formato Wav:
ls /tmp
[Link]
el sufijo mix indica que el archivo contiene los dos canales audio de la llamada y la primera parte del
nombre:
100932MGY5ZTQ1MWQyNTI1MWExYmJhNGE3NjY2N2E0YzU1MTI
es el contenido de la cabecera Call-ID de la llamada:
7
No he logrado localizar a que corresponde la segunda parte del nombre:
537558c787367f17
Si se les ocurre algo, me comentan en el foro de esta semana. Para bajar el archivo de configuración
como quedaría al terminar esta parte:
cd /etc/kamailio/
wget [Link]
se abre:
nano [Link]
se modifican las lineas 91, 92 y 397 cambiando IPPublica con la IP publica de su servidor. Se cambian
las lineas 93, 143 y 1088 modificando IPPrivada con la IP privada de su servidor; se modifica la linea
438 con el nombre del primer sub dominio asignado a su servidor; se modifica la linea 961 cambiando
[Link] con la IP publica de su servidor. Se guardan los cambios y se sobrescribe al archivo de
configuración predefinido:
cp [Link] [Link]
Se reinicia Kamailio:
systemctl restart kamailio
Con esta parte termina el modulo II. Empezaremos el próximo modulo hablando del balanceamiento de
carga iniciando con el modulo DISPATCHER
