xtables-addons-2.14 en FreePBX 15: make: *** /lib/…/build: No such file or directory. Stop.

Estaba queriendo instalar xtables-addons-2.14 en CentOS 7.8 o FreePBX 15 (Sangoma Linux release 7.8.2003 (Core) especificamente) usando tutoriales como el siguiente:

linoxide.com/block-ips-countries-geoip-addons

pero obtenía el siguiente error al hacer el ./configure :

checking Xtables module directory… /usr/lib64/xtables
checking kernel version that we will build against… make: *** /lib/modules/3.10.0-1127.19.1.el7.x86_64/build: No such file or directory. Stop.
0.0.0.0 in /lib/modules/3.10.0-1127.19.1.el7.x86_64/build
WARNING: That kernel version is not officially supported.

PJSIP syntax error exception when parsing ‘Contact’ header on line 8 col 10:

Si estás aquí por este error de sintaxis en PJSIP y no tenés idea de que lo causa, lo mejor es que revisés ese header, especificamente el Contact, yo sé que el error es bien explícito, pero por si acaso sos como yo que no entiende a la primera…

pjproject: sip_transport.c Error processing 393 bytes packet from UDP 193.107.216.181:5102 : PJSIP syntax error exception when parsing 'Contact' header on line 8 col 10:

En el header SIP/PJSIP se puede ver el «Contact: None» (línea 8, columna 10) que causa el error, proviene de un SIPVicious atacando un Asterisk con el puerto 5060 abierto, pero (según un Asterisk Technical Lead) al violar la especificación de SIP con ese Contact hace que la solicitud de SIP REGISTER sea inválida, por tanto PJSIP la bloquea (o dice que hubo un error de sintaxis)

Algunas expresiones de tshark para filtrar pcaps con información de protocolo SIP

A veces resulta prático leer el contenido de un pcap desde el CLI sin descargarlo y abrirlo con wireshark, talvez porque la información necesaria se puede desplegar desde la misma línea de comandos, el archivo pcap es muy grande y resulta poco práctico de manipular, o solo porque sí.

Tshark permite leer esas capturas de paquetes desde la misma línea de comandos usando lo que llaman «display filters» para mostrar los paquetes que coincidan con la expresión, pero que ya están guardados en el archivo.

Prefijos para operadores telefónicos en Nicaragua en Asterisk

Me llevó varias horas pasar los prefijos de cada operador del documento en excel que comparte Movistar con sus clientes a patrones en notación de asterisk (llamado pattern matching en la documentación). Por ello comparto los patrones, así se ahorra un par de horas alguien más:

Zabbix: Monitorear colas de Asterisk

Hice un script para agregar monitoreo de colas de asterisk (queues) y graficar miembros del queue disponibles y miembros con llamada.

Asterisk: Aplicar ChanSpy a un grupo de extensiones

Otro post que es más recordatorio para mi mismo que otra cosa. Normalmente estuve aplicando la función ChanSpy de Asterisk a una extensión digitada por quien llamaba:

Asterisk Authenticate: Generar archivo passwdfile con códigos aleatorios

Con cierta frecuencia me toca actualizar los códigos con los que autentico la salida a la PSTN desde extensiones internas. Cada vez que me toca vuelvo a buscar como generarlo en bash pero siempre olvido como la hice la última vez. Esta vez si lo documenté.

Asterisk: Monitorear SIP Trunk con Nagisk

Estoy recibiendo un E1 vía SIP Trunk por lo que la manera de monitorear el servicio no es la convencional, y por convencional me refiero a la que estoy acostumbrado y que está más ampliamente desplegada por los proveedores de telefonía en el país, recibir con un hardware E1 como una tarjeta PCI u otra.

Para vigilar el servicio al recibir de un convertidor de medios E1 hacia mi tarjeta E1 en Asterisk, uso el plugin de nagios check_e1t1 el cual monitorea el estado de sincronía de un puerto en específico usando el comando «dahdi show status» el cual a su vez depende de el archivo /dev/dahdi/ctl.

En el caso del troncal SIP no hay puerto físico que verificar por lo cual uso Nagisk, este plugin escrito en perl permite monitorear «peers» de Asterisk entre otras cosas.

La sintaxis correcta para monitorear una troncal en específico es:

/usr/local/nagios/lib/nagisk.pl -p NombreDeTroncal -c peer

La sintaxis que nos arroja la ayuda del comando no me quedaba muy clara:

Syntax: /usr/local/nagios/lib/nagisk.pl [-hv] [-c OPT] [-s NB|-p NAME|-b BUDDY] [-w TRESH -x TRESH]

Yendo al tema de cual de las dos tecnologías es mejor para recibir el servicio, soy nuevo en el tema de SIP Trunk, pero prefiero optar por él debido a que no hay hardware E1 de por medio actuando como SPOF (punto único de fallas).

Este es un gran dolor de cabeza para SysAdmins de PBX Asterisk o Elastix cuando se toman en cuenta costos de tarjetas E1, módulos de cancelación de eco, u otros y tiempo de importación en un país en el que ningún proveedor local mantiene este tipo de piezas en existencia o si quiera mantienen relaciones directas de socio comercial con fabricantes.

HDLC Abort (6) y HDLC Bad FCS (8) on D-channel of span 1

De un día para otro un E1 fraccionado de voz que me entrega un proveedor local empezó a producir un zumbido que únicamente era escuchado internamente, el zumbido o interferencia venía acompañado de mensajes de error y caídas de llamadas al abrirse el canal con la PSTN.

No se tenían alarmas de sincronía u otro indicio de que el medio físico estuviese fallando además de que el E1 se recibe por fibra óptica por lo que se descartaba que la interferencia fuese inducida por alguna línea eléctrica.

Los principales mensajes de error eran:

• PRI got event: HDLC Abort (6) on D-channel of span 1
• HDLC Bad FCS (8) on D-channel of span 1

Después de muchas horas y pruebas con otras tarjetas E1 y otros servidores volví a llamar a mi proveedor con la certeza de que algo había cambiado de su lado.

Resulta que habían deshabilitado el CRC de la señal del E1 y de mi lado seguía habilitado.

Procedieron a habilitarlo nuevamente y se limpiaron los errores.

También hubiese sido suficiente con deshabilitarlo en mi archivo /etc/dahdi/system.conf y reiniciar el dahdi:

# Autogenerated by /usr/sbin/dahdi_genconf on Sun Mar 29 00:47:35 2015
# If you edit this file and execute /usr/sbin/dahdi_genconf again,
# your manual changes will be LOST.
# Dahdi Configuration File
#
# This file is parsed by the Dahdi Configurator, dahdi_cfg
#
# Span 1: D130/0/1 «D130 (E1|T1) Card 0 Span 1» (MASTER) HDB3/CCS/CRC4
span=1,1,0,ccs,hdb3,crc4
# termtype: te
bchan=1-10
dchan=16
echocanceller=mg2,1-10

# Global data

loadzone = us
defaultzone = us

Nombre personalizado de grabaciones en asterisk-cdr-viewer

Por defecto asterisk-cdr-viewer usa el UNIQUEID de cada llamada como el nombre del archivo a buscar, esto para ofrecer la descarga de las grabaciones.

Para habilitar esta funcionalidad seguimos los siguientes pasos:

1. Como indica el ReadMe editamos el archivo config.inc.php para darle un valor acorde con nuestra configuracion a las variables $system_monitor_dir y $system_audio_format.
2. Grabar usando el UNIQUEID como nombre de archivo o usar el nombre personalizado en la funcion formatFiles.

El UNIQUEID resulta poco legible para identificar fechas de llamadas si deseamos manipularlas en grandes cantidades o con expresiones regulares, por ejemplo, cuando deseamos respaldar o borrar grabaciones de llamadas pasadas que nos ocupen mucho espacio en disco.

Por ello es preferible usar el formato propio y cambiar el valor de la cadena, en mi caso el valor fue:

$recorded_file = ‘Entrante_’.str_replace(‘ ‘,’_’,str_replace(array(‘-‘,’:’),»,$row[‘calldate’])).’-‘.$row[‘src’].’-Ext_’.substr($row[‘dst’],-4);