sip5060.net / en es

RSS Atom

Planet SIP

June 22, 2025

• Andrea Sannucci Como actualizar FreeSWITCH a la ultima versión disponible via Github

  Tengo un FreeSWITCH instalado en un CentOS 7 que utilizo más que nada para pruebas con OpenSIPs y Kamailio. Hoy decidí actualizarlo ya que la versión instalada es la:

   

  

   

  1.10.8, mientras la ultima versión disponible es la 1.10.12. Primero he creado una copia de las fuentes actuales:

   

  mkdir -p /usr/src/freeswitch-1.10.8

   

  cp -rf /usr/src/freeswitch/* /usr/src/freeswitch-1.10.8/

   

  luego de los archivos de configuración:

   

  mkdir -p /opt/freeswitch-conf

   

  cp -rf /etc/freeswitch/* /opt/freeswitch-conf/

   

  Terminada esa parte, se entra en la carpeta donde se encuentran las fuentes de FreeSWITCH, en mi caso:

   

  cd /usr/src/freeswitch

   

  y se actualizan las fuentes a los últimos cambios con el siguiente comando:

   

  git pull

   

  se continua con los comandos para la compilación:

   

  ./bootstrap.sh -j

   

  para evitar problemas de compilación comentan el modulo mod_signalwire:

   

  nano modules.conf

   

  cambian esta linea:

   

  applications/mod_signalwire

   

  con:

   

  #applications/mod_signalwire

   

  IMPORTANTE: en el siguiente comando cambien /usr/bin/python2 con /usr/bin/python3 dependiendo de la versión de Python instalada en su sistema:

   

  ./configure -C --enable-portable-binary \

  --prefix=/usr --localstatedir=/var --sysconfdir=/etc \

  --with-gnu-ld --with-python=/usr/bin/python2 --with-erlang --with-openssl \

  --enable-core-odbc-support --enable-zrtp \

  --enable-core-pgsql-support \

  --enable-static-v8 --disable-parallel-build-v8

  make

   

  se para FreeSWITCH:

   

  systemctl stop freeswitch

   

  se termina la instalación:

   

  make install

   

  se reinicia FreeSWITCH:

   

  systemctl start freeswitch

   

  se accede a la consola:

   

  fs_cli

   

  y se revisa si se actualizó la versión instalada:

   

  

   

  ¡Listo!

   

  • FreeSWITCH
  • GitHUB
  • Python

  Vota el Articulo: 

  VotarGive Como actualizar FreeSWITCH a la ultima versión disponible via Github 1/5Give Como actualizar FreeSWITCH a la ultima versión disponible via Github 2/5Give Como actualizar FreeSWITCH a la ultima versión disponible via Github 3/5Give Como actualizar FreeSWITCH a la ultima versión disponible via Github 4/5Give Como actualizar FreeSWITCH a la ultima versión disponible via Github 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

June 10, 2025

• Andrea Sannucci Kamailio y el modulo DMQ – Mensajería distribuida

  Kamailio, como seguramente ya saben, es un Proxy SIP de altas prestaciones y muy liviano. En entornos distribuidos o de alta disponibilidad, donde múltiples instancias de Kamailio trabajan en conjunto, es posible utilizar una configuración para sincronizar determinada información entre nodos. Es en este contexto donde entra en juego el módulo DMQ (Distributed Message Queue), diseñado para facilitar la comunicación entre múltiples nodos de Kamailio de manera eficiente y escalable. El módulo DMQ permite a las instancias de Kamailio intercambiar mensajes de manera distribuida utilizando un modelo de publicación y suscripción. Esto es especialmente útil en clústeres donde varios servidores comparten información de presencia, registros y diálogos, por ejemplo.

   

  Kamailio implementa con el modulo DMQ su propia lógica de mensajería sobre SIP, con un formato basado en JSON y transportado sobre UDP o TCP. Cada instancia de Kamailio que utilice DMQ debe estar configurada para identificarse de manera univoca y publicar datos sobre ciertos servicios (por ejemplo, presencia, diálogo, etc.) y suscribirse a datos publicados por otros nodos.

   

  Cuando un nodo necesita compartir una actualización, como un nuevo estado de presencia o un cambio de contacto, utiliza el módulo DMQ para enviar un mensaje a todos los nodos suscritos. Estos mensajes son procesados por los módulos correspondientes, como presence, dialog o dmq_usrloc, que están integrados con DMQ. La configuración básica de un nodo DMQ incluye la IP y puerto local, la lista de nodos remotos, el nombre del nodo y los módulos que usará DMQ.

   

  
  Una típica configuración del modulo DMQ sería:

  # ---- dmq params ----
  modparam("dmq", "server_address", "sip:10.0.0.3:5222")
  modparam("dmq", "notification_address", "sip:10.0.0.2:5222")
  modparam("dmq", "multi_notify", 0)
  modparam("dmq", "num_workers", 4)
  modparam("dmq", "ping_interval", 30)
  

  • en la segunda linea se pone la IP privada y el puerto del Servidor 1 que se utilizará para escuchar los mensajes SIP de tipo KDMQ

  • en la tercer linea se indica la IP Privada y el puerto del Servidor 2. Si se quisiera añadir un tercer servidor, se repetiría esta linea añadiendo IP Privada y puerto del tercer servidor

  • en la cuarta linea se pone en 1 si se trabaja con nombre de dominios en lugar de IP

  • en la quinta linea se indica el numero de hilos que se dedican al modulo

  • en la sexta y ultima linea cada cuanto se averiguará que los demás Kamailio estén funcionando y contestando los paquetes KDMQ enviados

  para que el modulo funcione se añade una nueva linea de listen que contendrá este valor:

  listen=udp:IPPrivada:5222

  en ambos servidores: esto para que el servidor se ponga a la escucha sobre la IP Privada y puerto configurados en el parámetro server_address del modulo.

  En la parte dedicada al Script de Kamailio, normalmente después de esta linea:

  request_route {

  se añade:

  if(is_method("KDMQ")) {
  dmq_handle_message();
  }

  Esto para que los mensajes SIP KDMQ se procesen correctamente. Los módulos que pueden aprovechar la configuración de este sistema de "mensajería" interna de Kamailio son:

   

  • DIALOG, para compartir los diálogos activos

  • DMQ_USRLOC, para compartir los registros de los usuarios

  • HTABLE, para compartir los datos guardados en las distintas tablas HASH utilizadas (ejemplo las IP Bloqueadas con el modulo PIKE)

  • PRESENCE, para compartir los datos de presencia

  Una vez terminada la configuración y reiniciados los dos servidores Kamailio, en SNGREP deberían empezar a aparecer mensajes SIP de este tipo:

   

  

   

  y en el mensaje KDMQ:

   

  

  
  Indicando que los dos servidores se encuentran activos. Cuando se registre un nuevo dispositivo en uno de los dos Kamailio, el mensaje KDMQ:

   

  

   

  Me comentan

  • Kamailio
  • Modulo DMQ
  • SIP KDMQ

  Vota el Articulo: 

  VotarGive Kamailio y el modulo DMQ – Mensajería distribuida 1/5Give Kamailio y el modulo DMQ – Mensajería distribuida 2/5Give Kamailio y el modulo DMQ – Mensajería distribuida 3/5Give Kamailio y el modulo DMQ – Mensajería distribuida 4/5Give Kamailio y el modulo DMQ – Mensajería distribuida 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

June 09, 2025

• Andrea Sannucci OpenSSL 3.0 y 3.x y las prestaciones del cifrado de la señalización SIP en Kamailio

  Hace unos días apareció un correo en la lista de distribución de los usuarios de Kamailio, donde se señalada un deterioro de las prestaciones del cifrado de la señalización SIP en Kamailio utilizando el modulo tls.so en entornos donde se utilizan muchas conexiones de este tipo (muchos usuarios que utilizan el cifrado de la señalización SIP). En este correo se indicaba un enlace que hace referencia a un análisis técnica que se hizo de las nuevas versiones de OpenSSL.

   

  En ese articulo se dice sustancialmente que los nuevos protocolos de cifrado y las nuevas librerías consuman muchos más recursos de las anteriores y además consuman mucha más energía afectando la las emisiones de carbono de los centros de datos donde se utilizan de manera masiva.

   

  Los desarrolladores de Kamailio aconsejan utilizar la versión 1.1.1 de OpenSSL o la librería WolfSSL, de la que he hablado en estos artículos, soportada por Kamailio a través del modulo tls_wolfssl.so.

   

  En Rocky Linux 9, la versión de OpenSSL instalada por defecto es:

   

  openssl -v

  OpenSSL 3.2.2 4 Jun 2024 (Library: OpenSSL 3.2.2 4 Jun 2024)

   

  Me comentan

   

  • Kamailio
  • WolfSSL
  • OpenSSL

  Vota el Articulo: 

  VotarGive OpenSSL 3.0 y 3.x y las prestaciones del cifrado de la señalización SIP en Kamailio 1/5Give OpenSSL 3.0 y 3.x y las prestaciones del cifrado de la señalización SIP en Kamailio 2/5Give OpenSSL 3.0 y 3.x y las prestaciones del cifrado de la señalización SIP en Kamailio 3/5Give OpenSSL 3.0 y 3.x y las prestaciones del cifrado de la señalización SIP en Kamailio 4/5Give OpenSSL 3.0 y 3.x y las prestaciones del cifrado de la señalización SIP en Kamailio 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

June 04, 2025

• Andrea Sannucci ¿Sigues utilizando Motores de Busqueda para tu Trabajo?
  Opciones

  Si

  No

  • 
  • 
  • 

May 31, 2025

• Andrea Sannucci Kamailio y el módulo dlgs: Monitoreo eficiente de diálogos SIP Stateless

  Kamailio es un SIP proxy de alto rendimiento ampliamente utilizado en redes VoIP a gran escala. Entre sus múltiples módulos se encuentra dlgs, el cual permite monitorear los diálogos SIP activos, brindando análisis de tráfico y control de recursos. Este artículo explica qué es dlgs, cómo funciona, para qué sirve y cómo se configura correctamente. El módulo dlgs se encarga de seguir el estado de los diálogos SIP dentro de Kamailio, manteniéndolos en estructuras de memoria compartida.

  Su enfoque está en ser ligero y eficiente, sin requerir base de datos, y útil para:

  • Visualizar llamadas activas en tiempo real

  • Limitar el número de llamadas concurrentes

  • Integrarse con paneles de monitoreo

  • Auditoría o estadísticas SIP básicas

  ¿Cómo funciona?

  Cada vez que se establece un diálogo SIP (normalmente tras el INVITE -> 200 OK -> ACK), dlgs lo almacena utilizando identificadores clave que pueden ser, por ejemplo, la cabecera call-id, o las banderas presentes en la cabeceras From y To.

  Mantiene un estado de vida del diálogo en tres etapas:

  1. Inicial (desde la creación hasta que se activa)

  2. Activo (una vez que se haya establecido la llamada)

  3. Finalizado (tras un BYE o un error)

  El módulo se encarga de limpiar automáticamente estos diálogos tras un tiempo que se configura a través de un temporizador

  Parámetros de configuración:

  loadmodule "dlgs.so"

  Y configuras los siguientes parámetros según tus necesidades:

  modparam("dlgs", "init_lifetime", 180)        # Diálogos iniciales modparam("dlgs", "active_lifetime", 10800)    # Diálogos activos modparam("dlgs", "finish_lifetime", 10)       # Diálogos finalizados modparam("dlgs", "timer_interval", 30)        # Intervalo de limpieza modparam("dlgs", "hash_size", 9)              # Tamaño tabla hash

  Ejemplo de uso en el script

  Dentro del script de Kamailio si queremos consultar cuántos diálogos activos hay:

  if(dlgs_count_active() > 100) {     xlog("L_WARN", "Demasiadas llamadas activas\n");     sl_send_reply("503", "Server Busy");     exit; }

  También se pueden usar comandos RPC para interactuar con el módulo:

  kamcmd dlgs.list kamcmd dlgs.stats

  Casos de uso reales

  • Gateways SIP: Limitar la carga de tráfico en función de sesiones vivas

  • Facturación: Obtener eventos de inicio/fin de llamadas

  • Auditoría SIP: Observar patrones de llamadas sin almacenar CDRs

  Consideraciones importantes

  • dlgs no almacena información en disco ni base de datos: todo está en memoria de trabajo de Kamailio

  • No genera CDRs ni maneja lógica de sesión como el módulo dialog

  • Es ideal para escenarios donde solo necesitas visibilidad ligera y rápida

  Conclusión

  El módulo dlgs es una herramienta poderosa y liviana si necesitamos controlar o visualizar el estado de las llamadas SIP en Kamailio. Aunque no tiene la riqueza funcional de dialog, es perfecto para escenarios donde eficiencia y bajo consumo de recursos son clave. En las ultimas versiones de los archivos predefinidos de la configuración de Kamailio, está presente.

  • Kamailio
  • DLGS
  • Proxy SIP

  Vota el Articulo: 

  VotarGive Kamailio y el módulo dlgs: Monitoreo eficiente de diálogos SIP Stateless 1/5Give Kamailio y el módulo dlgs: Monitoreo eficiente de diálogos SIP Stateless 2/5Give Kamailio y el módulo dlgs: Monitoreo eficiente de diálogos SIP Stateless 3/5Give Kamailio y el módulo dlgs: Monitoreo eficiente de diálogos SIP Stateless 4/5Give Kamailio y el módulo dlgs: Monitoreo eficiente de diálogos SIP Stateless 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

May 28, 2025

• Andrea Sannucci VideoCurso Proxy SIP Kamailio – Segunda edición Junio 2025

  El próximo 23 de junio empezará la segunda edición del videocurso dedicado al Proxy SIP Kamailio. Esta segunda edición sigue más o menos los mismos patrones de la primera:

   

  • 4 módulos semanales

  • 6 videoconferencias de 3 horas cada una los días 24-25-26 Junio y 1-2-3 Julio; todas a las 2pm hora de Colombia

  • más de 300 paginas de guías todas en español

  • acceso sin limites

  • acceso al foro para preguntas sin limite

  Costo del curso: 300 dólares

   

  Descuentos disponibles:

   

  • 10% para pronto pago/inscripción temprana; pagos realizados antes del 15 de Junio 2024;

  • 15% para empresas que inscriban 3 o más empleados.

  • 20% para antiguos estudiantes que ya participaron en un curso organizado por VozToVoice

   

  ¿Qué aprederán?

   

  • Preparación del Servidor Linux con Rocky Linux 64bit – Versión 9

  • Instalación de la ultima versión disponible de Kamailio de la rama 6.0

  • Kamailio como PBX (SWITCH de Clase 5):

    • Registro y localización

    • Llamadas entre extensiones, llamadas secuenciales, llamadas a grupos de dispositivos registrados con las mismas credenciales

    • Resolver problemas de NAT (señalización y audio de las llamadas) utilizando un Media Proxy (RTPEngine)

    • Transcodificación Codec Audio en las llamadas y grabación de las llamadas a través de RTPEngine

    • Presencia y mensajes instantáneos

    • Llamadas entrantes desde números geográficos y salientes con troncales SIP

    • Instalación y configuración de un Servidor media para servicios media: conferencias audio, correo de voz y test de echo utilizando Asterisk PBX o FreeSWITCH)

    • Configurar distintas empresas/clientes en el mismo servidor (Multi dominio)

    • Cifrado señalización SIP y flujo media (TLS y SRTP) y WebRTC

    • Llamadas SIP-TLS y TLS-SIP; llamadas SIP-WebRTC – WebRTC-SIP

  • Kamailio como balanceador de carga (SWITCH de Clase 4):

    • Modulo DISPATCHER (Outbound Proxy y protocolo PATH). Como distribuir todas las solicitudes SIP o solamente las llamadas entre dos servidores Asterisk PBX.

    • Modulo LCR. Distribución de llamadas basadas en prefijos, pesos y prioridades

    • modulo DROUTING. Distribución de llamadas basada en reglas y permisos

  • Integración de Kamailio con Asterisk PBX:

    • Autenticación en Kamailio

    • Registro y localización de los dispositivos en Kamailio

    • Llamadas entre extensiones en Asterisk

    • Llamadas entrantes y salientes en Kamailio

    • Servicios Media (IVR, Buzón de voz, etc) en Asterisk

  • Integración de Kamailio con FreeSWITCH:

    • Autenticación en Kamailio

    • Registro y localización de los dispositivos en Kamailio

    • Llamadas entre extensiones en FreeSWITCH

    • Llamadas entrantes y salientes en Kamailio

    • Servicios Media (IVR, Buzón de voz, etc) en FreeSWITCH

    • Configuración multidominio

  • Conocer como configurar Kamailio en Alta disponibilidad con Keepalived o Pacemaker y Corosync en Amazon AWS (videoconferencia dedicada)

  • Gestionar y configurar Kamailio desde una Consola Web (Siremis)

  • Puesta en seguridad de Kamailio:

    • modulo SANITY

    • modulo PIKE

    • modulo SECFILTER

    • modulo TOPOH

    • modulo TOPOS

    • Fail2BAN

    • Cuenta de canales

    • RATELIMIT

  • Monitoreo de Kamailio:

    • Homer SIP Capture Server

    • MONIT

    • Protocolo SNMP y Nagios

  Formulario de inscripción.

   

  • Kamailio
  • Proxy SIP
  • VideoCurso

  Vota el Articulo: 

  VotarGive VideoCurso Proxy SIP Kamailio – Segunda edición Junio 2025 1/5Give VideoCurso Proxy SIP Kamailio – Segunda edición Junio 2025 2/5Give VideoCurso Proxy SIP Kamailio – Segunda edición Junio 2025 3/5Give VideoCurso Proxy SIP Kamailio – Segunda edición Junio 2025 4/5Give VideoCurso Proxy SIP Kamailio – Segunda edición Junio 2025 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

May 19, 2025

• Andrea Sannucci OpenSIPs 3.6: IP y Puerto de escucha dinámicos

  Una novedad realmente muy interesante de la próxima versión de OpenSIPs, la 3.6, es la posibilidad de definir trasporte, IP y puerto de escucha de manera dinámica utilizando la nueva tabla sockets de la base de datos de OpenSIPs que es posible crear a lo largo de la instalación del Proxy SIP. Hasta el momento si se cambiaba el parámetro global socket de OpenSIPs, había que reiniciar el programa. Lo mismo pasa con Kamailio pues en esto le ganaría OpenSIPs.

   

  Con la nueva funcionalidad, proveída por el modulo sockets_mgm, será posible utilizar la nueva tabla para añadir, modificar, eliminar los datos de escucha y luego recargar la configuración con un comando parte del modulo. Desde ese momento OpenSIPs, sin que se reinicie, empezará a escuchar sobre los nuevos valores configurados. La tabla se compone de 6 columnas:

   

  • id: se auto incrementa de una unidad por cada nueva entrada

  • socket: el valor de trasporte, IP y puerto donde se pondrá a la escucha OpenSIPs. Ejemplo: "udp:1.2.3.4:5060"

  • advertised: IP y puerto publicos si OpenSIPs se encuentra detrás de un NAT, como es el caso de Amazon AWS.

  • tag: una etiqueta para identificar de manera univoca el socket de escucha. Útil cuando el Proxy SIP es parte de un Cluster de servidores OpenSIPs

  • flags: son banderas que complementan la configuración. Posibles valores:

    • anycast

    • reuse_port

    • frag

  • tos: type of services. Utilizado para marcar los paquetes para sean procesados con más o menos prioridad

  Ahora que sabemos que valores acepta la tabla, miramos los parámetros más importantes del modulo:

   

  • db_url: para definir el enlace de conexión a la base de datos; ejemplo: "mysql://opensips:opensipsrw@localhost/opensips"

  • processes: números de procesos dedicados al trasporte UDP. Valore predefinido 8

  • max_sockets: numero máximo de sockes que se pueden definir dinámicamente utilizando la tabla de la base de datos

  Una vez creadas y/o modificadas las entradas, para recargar la configuración al vuelo:

   

  opensips-cli -x mi sockets_reload

   

  para ver la lista de sockets definidos/activos:

   

  opensips-cli -x mi sockets_list

   

  Limitaciones del modulo:

   

  • los sockets con protocolo de trasporte UDP podrán utilizar SOLAMENTE los procesos definidos en el parámetro processes del modulo

  • no se pueden utilizar para definir socket de tipo BIN (utilizado en una configuración de cluster de servidores) o HEP (utilizado para enviar la captura de la señalización SIP a un servidor externo tipo Homer SIP Capture Server

  • no es posible utilizar el nombre de una interfaz de red o un alias para definir un socket; solamente IP y Puerto

  • el numero di socket dinámicos que se podrán utilizar serán aquellos definidos en el parámetro max_sockets del modulo y no se podrán modificar hasta que no se reinicie el Proxy SIP

  A mi me parece una novedad muy interesante, ahora solamente hace falta probarla cuando sea liberada la primera versión de la rama 3.6 de OpenSIPs. Les recuerdo que esa versión será con soporte a largo plazo y suplantará la versión 3.4

   

  • OpenSIPs 3.6
  • Proxy SIP
  • sockets
  • modulo sockets_mgm

  Vota el Articulo: 

  VotarGive OpenSIPs 3.6: IP y Puerto de escucha dinámicos 1/5Give OpenSIPs 3.6: IP y Puerto de escucha dinámicos 2/5Give OpenSIPs 3.6: IP y Puerto de escucha dinámicos 3/5Give OpenSIPs 3.6: IP y Puerto de escucha dinámicos 4/5Give OpenSIPs 3.6: IP y Puerto de escucha dinámicos 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

April 09, 2025

• Andrea Sannucci Cursos a distancia: FreeSWITCH + OpenSIPs Cluster + Kamailio (Videocurso)

  Como anunciado en el canal Telegram de VozToVoice https://t.me/voztovoice, vamos a lanzar un paquete de cursos que incluye FreeSWITCH, OpenSIPs Cluster y Kamailio (Videocurso) a un precio interesante y ofreciendo, de esta forma, una formación bastante completa de las herramientas SIP hablantes, disponibles en el mundo Open Source. Se realizarán comparaciones entre los distintos programas de forma que al momento de tener que implementar un escenario, se podrá saber cual será el programa que ofrecerá más desempeño para esa determinada configuración.

   

  Para aquellos que quieran participar los cursos tendrán el siguiente calendario:

   

  • FreeSWITCH: 5 Mayo – 25 Mayo 2025

  • OpenSIPs Cluster: 26 Mayo – 22 Junio 2025

  • Videocurso Kamailio 6.0: con Videoconferencias el 24-25-26 Junio y el 1-2-3 Julio a las 2pm hora de Colombia

  El precio total de los tres cursos será de 500 dólares, 450 Euros o 2.000.000 de pesos colombianos. Si tomados singularmente el costo sería:

   

  • FreeSWITCH: 170 dólares

  • OpenSIPs Cluster: 250 dólares

  • Videocurso Kamailio: 300 dólares

  por un Total de: 720 dólares. Aunque puedan aprovechar del descuento más alto (antiguos alumnos, 20%), el costo total sería de 576 dólares, es decir siempre más alto del paquete completo.

   

  En el anexo presente con esta entrada están informaciones y temarios de cada curso. Léanlo atentamente y me comentan campus@mesaproyectos.com

   

  Los cupos son limitados (máximo 8).

   

  IMPORTANTE: es posible inscribirse a cada curso singularmente una vez que se abran las inscripciones. En este momento el único curso abierto es de FreeSWITCH

   

  Si interesados, rellenen el formulario de inscripción.

   

  Adjunto	Tamaño
  cursos-freeswitch-opensips-kamailio.pdf	249.72 KB

  • FreeSWICTH
  • OpenSIPs
  • Kamailio
  • Curso a distancia

  Vota el Articulo: 

  VotarGive Cursos a distancia: FreeSWITCH + OpenSIPs Cluster + Kamailio (Videocurso) 1/5Give Cursos a distancia: FreeSWITCH + OpenSIPs Cluster + Kamailio (Videocurso) 2/5Give Cursos a distancia: FreeSWITCH + OpenSIPs Cluster + Kamailio (Videocurso) 3/5Give Cursos a distancia: FreeSWITCH + OpenSIPs Cluster + Kamailio (Videocurso) 4/5Give Cursos a distancia: FreeSWITCH + OpenSIPs Cluster + Kamailio (Videocurso) 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

April 07, 2025

• Andrea Sannucci Curso FreeSWITCH 1.10.X - Quinta Edición - Mayo 2025

  A partir de este momento, están abiertas las inscripciones a la quinta edición del curso a distancia dedicado a FreeSWITCH, uno Switch/PBX muy versatil y potente que permite configuraciones bastantes detalladas y escalables. El curso tiene una duración de 3 semanas y empezará el próximo 5 de Mayo 2025. Es posible adquirir este curso junto al curso de OpenSIPs Cluster y Kamailio TLS/WebRTC - Balanceo/Alta Disponibilidad.

  Si quieren participar a los tres cursos a la vez, esperen que salga una próxima entrada donde se explicará como inscribirse a los tres cursos a la vez. Si están interesados solamente en este curso, ya pueden rellenar el formulario de inscripción.

  Requisitos para inscribirse:
      • Conocimientos básicos de Linux (distribución Rocky Linux/Almalinux) 
      • Acceso a Internet de banda ancha 
      • Lectura inglés técnico básico

  ¿Que Aprenderé?

  • Preparación del Servidor Linux (VPS remoto) con Rocky Linux 9

  • Instalación de FreeSWITCH 1.10.12 o superior desde las fuentes

  • Configuración del cortafuegos

  • Arquitectura de FreeSWITCH (Corazón y módulos)

  • Que son y como se configuran los Perfiles SIP

  • Negociación de Codec básica y avanzada

  • Solucionar problemas de NAT

  • Las expresiones regulares utilizadas en el Dialplan (PCRE - Perl Compatible Regular Expressions)

  • Endpoint/Extensiones, Dialplan y Contextos

  • Dialplan básico y avanzado (llamadas entrantes y salientes)

  • Concepto y uso de las Phrase Macros

  • Como utilizar el Buzón de voz

  • Como configurar un IVR

  • Llamadas seguras (TLS, SRTP)

  • Conferencias audio y Videoconferencias

  • WebRTC SIP y VERTO

  • Configuración Multi Dominio, Multi Utente

  • Respaldo de llamadas

  • Monitoreo y seguridad del sistema

  ¿Cuanto cuesta?

  El valor del curso es de 170 dólares, 156 Euros o 750mil Pesos Colombianos (COP).

  Descuentos:

  • 10% pronto pago/inscripción temprana; pagos realizados antes del 27 de Abril 2025

  • 15% para grupos de 3 o más personas de la misma empresa

  • 20% para inscritos que ya han participado en un curso organizado por VozToVoice

  Formas de pago:

  • PayPal

  • Tarjeta de crédito

  • Transferencia bancaria Colombia

  • Transferencia bancaria Europa

  • Transferencia bancaria USA

  En anexo encuentran el temario completo. Cualquier cosa pueden escribir a campus@mesaproyectos.com

  Me comentan

   

   

  Adjunto	Tamaño
  programa_curso_freeswitch.pdf	108.91 KB

  • FreeSWICTH
  • pbx
  • Curso a distancia

  Vota el Articulo: 

  VotarGive Curso FreeSWITCH 1.10.X - Quinta Edición - Mayo 2025 1/5Give Curso FreeSWITCH 1.10.X - Quinta Edición - Mayo 2025 2/5Give Curso FreeSWITCH 1.10.X - Quinta Edición - Mayo 2025 3/5Give Curso FreeSWITCH 1.10.X - Quinta Edición - Mayo 2025 4/5Give Curso FreeSWITCH 1.10.X - Quinta Edición - Mayo 2025 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

March 17, 2025

• Andrea Sannucci IA y la lenta y paulatina muerte de los Blogs

  Con la entrada prepotente e imparable de la inteligencia artificial generativa en nuestras vidas y nuestros trabajos, unos de los “servicios” que seguramente irán desapareciendo paulatinamente, serán los Blog. ¿Porque digo esto? Porque, por lo menos por mi experiencia personal, es mucho más sencillo, rápido y, en la mayoría de los casos, acertado, realizar consultas a una IA generativa que buscando en la Web; luego si falta algún dato o se quiere corroborar que la información facilitada es cierta, se puede complementar con una búsqueda más precisa.

   

  En estos días estoy usando ChatGPT para realizar búsquedas relacionadas con FreeSWITCH y Kamailio para los próximos cursos, y la verdad ChatGPT todavía dice una cantidad de cosa inexactas que casi da risa y asusta al mismo tiempo. Claramente son temas de nicho, con poca documentación en linea, pero falla demasiado. Lo peor es que si uno la corriges, admite el error y en seguida inventa otra mentira; si les pasa eso, les aconsejo buscar en la documentación oficial o en la Web.

   

  Ahora, para temas un poco más sencillos, nos hace ahorrar mucho, pero mucho tiempo. ¿Un Ejemplo? Quería saber si podía instalar PHP 7.4 en Rocky Linux 9 y la primera respuesta fue que tenía que instalar los repositorios remi y luego ejecutar una serie de comandos. Como la primera respuesta no me funcionó, ya que Rocky Linux me devolvía un error, le pasé el error a la IA y en seguida me propuso una solución que funcionó sin problemas.

   

  Para terminar, así define ChatGPT a si misma:

   

  “¡Buena pregunta! Funciono como un modelo de inteligencia artificial basado en aprendizaje automático. Estoy entrenado en una gran cantidad de texto y utilizo redes neuronales avanzadas para entender y generar lenguaje de manera coherente.

  Aquí un resumen de cómo trabajo:

  1. Procesamiento del texto: Cuando me haces una pregunta, convierto tu mensaje en una representación matemática para entenderlo.

  2. Generación de respuesta: Analizo el contexto y predigo la mejor respuesta basándome en patrones de lenguaje que he aprendido.

  3. Optimización: Intento que mis respuestas sean claras, útiles y adaptadas a lo que necesitas.

  4. Interacción con herramientas: Puedo buscar información actualizada en la web, ejecutar código, generar imágenes y manejar documentos si lo necesitas.

  No tengo memoria propia, pero en esta conversación puedo recordar lo que dijimos antes para mantener la coherencia. En algunas situaciones, también puedo guardar información relevante para ayudarte mejor en el futuro.

  Si tienes curiosidad por algo más técnico o específico, dime. ¡Me encanta hablar de estas cosas!"

  • IA
  • AI
  • Blog

  Vota el Articulo: 

  VotarGive IA y la lenta y paulatina muerte de los Blogs 1/5Give IA y la lenta y paulatina muerte de los Blogs 2/5Give IA y la lenta y paulatina muerte de los Blogs 3/5Give IA y la lenta y paulatina muerte de los Blogs 4/5Give IA y la lenta y paulatina muerte de los Blogs 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

March 06, 2025

• Andrea Sannucci Digest Authentication SHA-256 Asterisk PBX 20.12 → Kamailio

  En este articulo les conté que Asterisk PBX, desde la versión 20.12, soporta la digest authentication utilizando, además de MD5, SHA-256 y SHA-512-256. En este nuevo articulo veremos como registrar un usuario configurado en Asterisk PBX en Kamailio utilizando el cifrado SHA-256 che está soportado también en Kamailio. Los pasos a seguir son:

   

  1. modificar el archivo de configuración de Kamailio utilizado para la creación de la base de datos de Kamailio

  2. crear usuarios utilizando el cifrado SHA-256

  3. configurar el usuario en Asterisk PBX apuntando a Kamailio

   

  Claramente no puedo hacer un paso a paso desde la instalación de Kamailio pero todo lo que se describe aquí, se incluirá en el próximo curso de Kamailio. Empecemos con el archivo de configuración utilizado en kamailio para crear la base de datos:

   

  nano /etc/kamailio/kamctlrc

   

  la linea que nos interesa es:

   

  # MD5="md5sum"

   

  que es donde se indica que cifrado se va a utilizar a la hora de crear los usuarios. Cambiando el valor según se necesite, podremos crear usuarios con la contraseña cifrada con MD5 o con SHA-256. Los dos respectivos valores serían:

   

  MD5="md5sum"

   

  y

   

  MD5="sha256sum"

   

  claramente si se utiliza un valor no se puede utilizar el otro, es decir que el archivo no acepta la presencia de los dos valores a la vez. Luego se crean los usuarios utilizando el comando:

   

  kamctl add usuario contraseña

   

  Yo he creado unos con MD5 y unos con SHA-256

   

  

  

   

  Aquellos que tienen una longitud más larga en las columnas ha1 y ha1b se han creado con el cifrado SHA-256. Otro parámetro importante en la configuración de Kamailio es:

   

  nano /etc/kamailio/kamailio.cfg

   

  modparam("auth", "algorithm", "SHA-256")

   

  donde se indica que tipo de Digest Auhtentication soportará Kamailio. Con la versión 6.0 de Kamailio ya es posible utilizar una función, siempre del modulo AUTH, para definir el tipo de cifrado utilizado dentro de la parte dedicada al enrutamiento; esto significa que se puede modificar según el dispositivo con que se comunique Kamailio. Ahora pasamos a la configuración del archivo de Asterisk dedicado al canal chan_pjsip:

   

  nano /etc/asterisk/pjsip.conf

   

  donde al final del archivo se copian las lineas que siguen:

   

  [no-nat]

  type=transport

  protocol=udp

  bind=10.10.0.2:5080

  allow_reload=yes

   

  [1010]

  type=registration

  server_uri=sip:1010@10.10.0.2

  client_uri=sip:1010@10.10.0.2

  contact_user=1010

  expiration=600

  max_retries=10

  retry_interval=60

  outbound_auth=aut-1010

  transport= no-nat

  support_path=yes

   

  [1010]

  type=endpoint

  transport=no-nat

  from_user=1010

  context=from-externas

  subscribe_context=subscribe-pjsip

  disallow=all

  allow=alaw,g722

  outbound_auth=aut-voztovoice

  aors=1010

   

  [aut-1010]

  type=auth

  auth_type=digest

  username=1010

  password=sesamo

  supported_algorithms_uac=MD5,SHA-256

  ;supported_algorithms_uas=MD5,SHA-256

   

  [1010]

  type=aor

  qualify_frequency=30

  contact=sip:10.10.0.2:5060

   

  [1010]

  type=identify

  endpoint=1010

  match=10.10.0.2:5060

   

  Kamailio estará a la escucha sobre la IP 10.10.0.2 y puerto 5060. El bloque importante es:

   

  [aut-1010]

  type=auth

  auth_type=digest

  username=1010

  password=sesamo

  supported_algorithms_uac=MD5,SHA-256

   

  Sonde se define que el UAC soportará MD5 y SHA-256. Asterisk PBX es un User Agent Client cuando genera la solicitud SIP come es en este caso. Se inicia/reinicia Asterisk PBX. Una vez que Kamailio recibirá el primer Register de Asterisk:

   

  

   

  contestará con:

   

  

   

  y Asterisk PBX contestará con:

   

  

   

  200OK final de Kamailio:

   

  

   

  Creo que es todo

   

   

  • Asterisk 20.12
  • Kamailio
  • Proxy SIP
  • SHA-256
  • REGISTER

  Vota el Articulo: 

  VotarGive Digest Authentication SHA-256 Asterisk PBX 20.12 → Kamailio 1/5Give Digest Authentication SHA-256 Asterisk PBX 20.12 → Kamailio 2/5Give Digest Authentication SHA-256 Asterisk PBX 20.12 → Kamailio 3/5Give Digest Authentication SHA-256 Asterisk PBX 20.12 → Kamailio 4/5Give Digest Authentication SHA-256 Asterisk PBX 20.12 → Kamailio 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

March 01, 2025

• Andrea Sannucci Desde Asterisk 20.12 soporte para SHA-256 y SHA-512-256

  El sistema de autenticación de Asterisk se basa en la RFC2617 que utiliza como método de cifrado MD5. En otro articulo estuve hablando justamente de ese método de cifrado diciendo que desde hace tiempo ya no es considerado seguro. Así que hoy, leyendo la noticia, me ha alegrado saber que Asterisk PBX, desde la versión 20.12, liberada el 6 de febrero, soporta dos métodos de cifrado nuevos y mas seguros:

   

  • SHA-256

  • SHA-512-256

  El primer método de cifrado es soportado también por Kamailio, pues cuando se necesite se podrá autenticar Asterisk hacia Kamailio o viceversa utilizando este método de cifrado descrito en la RFC7616 que vuelve obsoleta la RFC2617.

   

  Ahora, para que este método de cifrado funcione correctamente, se necesita:

   

  • mínimo la versión 2.15.1 de la pila SIP PJSIP

  • mínimo la versión 1.0.0 de OpenSSL para SHA-256

  • mínimo la versión 1.1.1 de OpenSSL para SHA-512-256

  Claramente esto funciona solamente con el canal PJSIP donde, en el bloque de autenticación habrá que cambiar los valores del parámetro auth_type que ahora serán:

   

  • digest: para usar el nuevo algoritmo de cifrado o la contraseña en texto plano

  • google_oauth: la autenticación de Google utilizada en Google Voice

  Se vuelven obsoletos los siguientes valores:

   

  • userpass

  • md5

  y el siguiente parámetro:

   

  • md5_cred

  En su lugar, habrá que crear tantas lines con el siguiente parametro:

   

  password_digest

   

  cuantas son las contraseñas HASH utilizadas. Ejemplo: si queremos que el usuario pueda utilizar la contraseña en MD5 y SHA-256, primero las creamos utilizando la siguiente sintaxis:

   

  echo -n "usuario:realm:contraseña" | openssl dgst -MD5

  echo -n "usuario:realm:contraseña" | openssl dgst -SHA-256

   

  y luego utilizamos los resultados en los respectivos parámetros:

   

  password_digest=MD5:60c68ed23939227701ada9bb5c6e0bdf

   

  password_digest=SHA-256:da8fdec73644114cda0d59ac3e97b7db499caed7e05189c00c9e9eb59a437348

   

  y para terminar indicamos que se pueden utilizar los dos metodos de cifrado para el UAC y UAS:

   

  supported_algorithms_uac=SHA-256,MD5

  supported_algorithms_uas=SHA-256,MD5

   

  Yo creo que el problema es otro: ¿Conocen Softphone o teléfonos de mesa que soportan estos nuevos métodos de cifrado? Yo personalmente no.

  • Asterisk 20.12
  • MD5
  • SHA-256
  • SHA-512-256

  Vota el Articulo: 

  VotarGive Desde Asterisk 20.12 soporte para SHA-256 y SHA-512-256 1/5Give Desde Asterisk 20.12 soporte para SHA-256 y SHA-512-256 2/5Give Desde Asterisk 20.12 soporte para SHA-256 y SHA-512-256 3/5Give Desde Asterisk 20.12 soporte para SHA-256 y SHA-512-256 4/5Give Desde Asterisk 20.12 soporte para SHA-256 y SHA-512-256 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

February 28, 2025

• Andrea Sannucci Librería bcg729 y RTPEngine [SOLVED]

  No se a cuantos de ustedes últimamente les se ha presentado este problema. Una vez compilada la librería bcg729, que nos permite poder transcodificar con el codec audio G729 con RTPEngine, al momento de compilar la ultima versión disponible en Github de este Proxy Media, la compilación fallaba y salía este error:

   

  

  Por el momento había solucionado descargando la versión 12.4 de RTPEngine donde este error no se presentaba, pero, como pueden entender, no era una solución a largo plazo. La solución verdadera es compilar la librería bcg729 con dos opciones, es decir:

   

  cd /usr/src/

   

  git clone https://github.com/BelledonneCommunications/bcg729.git

   

  cd bcg729

   

  cmake -DCMAKE_C_FLAGS="-fPIE" -DCMAKE_EXE_LINKER_FLAGS="-pie" .

   

  make

   

  make install

   

  luego continuar normalmente con RTPEngine:

   

  cd /usr/src

   

  git clone https://github.com/sipwise/rtpengine.git

   

  cd rtpengine/daemon

   

  make

   

  cp rtpengine /usr/local/bin/

   

  etc...

  • bcg729
  • RTPEngine
  • Kamailio

  Vota el Articulo: 

  VotarGive Librería bcg729 y RTPEngine [SOLVED] 1/5Give Librería bcg729 y RTPEngine [SOLVED] 2/5Give Librería bcg729 y RTPEngine [SOLVED] 3/5Give Librería bcg729 y RTPEngine [SOLVED] 4/5Give Librería bcg729 y RTPEngine [SOLVED] 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

February 17, 2025

• Andrea Sannucci Instalación Kamailio 6.0 en Rocky Linux 9 utilizando CMAKE

  Desde la versión 6.0 de Kamailio, que ha sido liberada hace unos días, la compilación de Kamailio se basa en cmake y aunque se pueda todavía utilizar make, dentro de poco el antiguo método de compilación se quitará de las fuentes de Kamailio. Es por eso que creo puede ser útil ver como es el proceso de instalación de Kamailio utilizando CMAKE.

   

  Una vez que tengamos acceso al servidor tenemos que instalar toda una serie de paquetes que luego utilizaremos para la compilación de Kamailio. Primero desactivamos Selinux y actualizamos el sistema:

   

  nano /etc/selinux/config

   

  SELINUX=disabled

   

  se guardan los cambios y:

   

  dnf update -y

   

  si en la actualización está incluida una nueva versión del Kernel, al terminar la actualización se reinicia el servidor:

   

  reboot

   

  se accede nuevamente y se continua con:

   

  dnf install git nano wget epel-release

   

  dnf config-manager --set-enabled crb

   

  dnf install mariadb-devel mariadb-server gcc gcc-c++ bison bison-devel net-tools \

  libgcrypt-devel flex make expat expat-devel net-snmp-devel libxml2 libxml2-devel git xmlto \

  libmicrohttpd-devel openssl-devel xmlrpc-c-devel lynx pcre pcre-devel ncurses-devel \

  ncurses-libs gdb net-snmp net-snmp-devel net-snmp-libs net-snmp-utils jansson-devel libuuid \

  libuuid-devel uuid uuid-devel ruby-devel spandsp-devel gperf sqlite sqlite-devel \

  lksctp-tools-devel python3-devel libjwt-devel openldap openldap-clients \

  openldap-devel openldap libmemcached-devel systemd-devel unixODBC unixODBC-devel \

  mariadb-connector-odbc libtool-ltdl-devel libtool mono-devel hiredis-devel \

  perl-ExtUtils-Embed libpurple-devel lua-devel libdb-cxx-devel libunistring-devel thrift-devel \

  libevent-devel json-c-devel librabbitmq-devel -y

   

  wget -q -O - https://updates.atomicorp.com/installers/atomic | sh

   

  A las dos preguntas que aparecen se contesta con YES, luego:

   

  dnf install GeoIP-devel libmaxminddb-devel bind bind-devel libev-devel libmnl-devel \

  expat-devel libwebsockets-devel -y

   

  Terminada la instalación de las dependencias, descargamos la ultima versión disponible de Kamailio de la rama 6.0 (en este momento la 6.0.0):

   

  cd /usr/src

  git clone --depth 1 --no-single-branch https://github.com/kamailio/kamailio kamailio

  Entramos en la carpeta creada:

   

  cd kamailio

   

  Pasamos a la rama 6.0:

   

  git checkout -b 6.0 origin/6.0

  branch '6.0' set up to track 'origin/6.0'.

  Switched
to a new branch '6.0'

   

  creamos
la carpeta utilizada por Cmake para la compilación:

   

  mkdir
build

   

  entramos
en la carpeta:

   

  cd
build

   

  y
empezamos con la compilación:

   

  cmake
..

   

  luego
para definir la carpeta predefinida de instalación:

   

  cd
..

   

  cmake
-DCMAKE_INSTALL_PREFIX=/

   

  para
añadir módulos que no se
compilan
por defecto:

   

  cmake
-DINCLUDE_MODULES="db_mysql http_async_client http_client tls
tlsa websocket"

   

  para terminar:

   

  make

   

  make install

   

  para ver la versión instalada:

   

  kamailio -V

   

  version: kamailio 6.0.0-rc0 (x86_64/Linux) 94a546-dirty

  flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED

  ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB

  poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.

  id: 94a546 dirty

  compiled on 10:54:09 Feb 17 2025 with gcc 11.5.0

   

  Por ahora es todo

   

  • Rocky Linux 9
  • Proxy SIP
  • Kamailio 6.0.0

  Vota el Articulo: 

  VotarGive Instalación Kamailio 6.0 en Rocky Linux 9 utilizando CMAKE 1/5Give Instalación Kamailio 6.0 en Rocky Linux 9 utilizando CMAKE 2/5Give Instalación Kamailio 6.0 en Rocky Linux 9 utilizando CMAKE 3/5Give Instalación Kamailio 6.0 en Rocky Linux 9 utilizando CMAKE 4/5Give Instalación Kamailio 6.0 en Rocky Linux 9 utilizando CMAKE 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

February 03, 2025

• Andrea Sannucci SEMS está de vuelta – Instalación en Rocky Linux 9

  Aquellos que han participados en mis cursos, sobre todo de OpenSIPs, ya conocen SEMS; SEMS es un Media Server muy liviano, modular, que permite la configuración de todas una serie de servicios entres los cuales:

   

  • conferencias audio

  • buzón de voz

  • test de echo

  Además de eso puede actuar como Session Border Controller (SBC) brindando los siguientes servicios:

   

  • cambio de identidad

  • manipulación de cabeceras

  • Manejo de flujos RTP

  • Detección de NAT

  • Transcodificación

  • SIP Autenticación

  • Session Timer

  • Call Timer

  • Llamadas prepagadas

  La ultima versión que hasta hace poco estaba disponible, la 1.6.0, no compilaba correctamente en Rocky Linux 9, pero parece que hace un par de meses salió la 1.7.0 que si compila correctamente en esta distribución de Linux. A seguir los pasos para compilar e instalar SEMS 1.7.0. Como pre-requisitos necesitamos todos los paquetes utilizados para compilar desde las fuentes y además Cmake y Git:

   

  dnf group install "Development Tools"

   

  dnf install spandsp* flac* speex* opus* gsm* hiredis git cmake -y

   

  Seguimos bajando las fuentes:

   

  cd /usr/src

   

  git clone https://github.com/sems-server/sems.git

   

  Entramos en la carpeta creada:

   

  cd sems/

   

  mkdir -p builds

   

  cd builds/

   

  compilamos:

   

  cmake ..

   

  make

   

  e instalamos:

   

  make install

   

  Terminada la compilación e instalación se crearán un serie de carpetas relacionadas con SEMS:

   

  • /usr/local/sbin contendrá el programa ejecutable de SEMS y unas utilidades

  • /etc/sems contendrá el archivo de configuración de sems y una carpeta /etc donde se encontrarán todos los archivos de configuración predefinidos de los distintos módulos disponibles

  • /usr/local/lib/sems contendrá a su vez tres carpetas; las que normalmente interesan:

    • audio: con todos los archivos de audio de todos los módulos (solamente en inglés)

    • plug-in: con todos los módulos compilados

       

  Podemos continuar con la instalación del script de arranque de SEMS. Como este script inicia el programa con usuario y grupo sems, hay que crearlos:

   

  useradd -M -U sems

   

  cd ../pkg/rpm/

   

  Abrimos este archivo:

   

  nano sems.systemd.service

   

  y modificamos esta linea:

   

  ExecStart=/usr/sbin/sems -E -u sems -g sems -P /var/run/sems/sems.pid $OPTIONS

   

  para que quede:

   

  ExecStart=/usr/local/sbin/sems -E -u sems -g sems -P /var/run/sems/sems.pid $OPTIONS

   

  Esto porque el programa se encuentra en la carpeta /usr/local/sbin y no /usr/sbin. Guardamos los cambios y creamos la carpeta para el archivo sems.pid como indicado en el archivo de configuración del script:

   

  mkdir -p /var/run/sems

   

  copiamos el archivo de arranque:

   

  cp sems.systemd.service /usr/lib/systemd/system/sems.service

   

  activamos para que arranque en automático:

   

  systemctl enable sems

  Created symlink from /etc/systemd/system/multi-user.target.wants/sems.service to /usr/lib/systemd/system/sems.service

   

  Copiamos dos archivos necesarios para que todo funcione correctamente:

   

  cp sems.sysconfig /etc/sysconfig/sems

   

  cp sems.systemd.tmpfiles.d.conf /etc/tmpfiles.d/sems.conf

   

  creamos la carpeta /var/spool/voicebox donde se guardarán los archivos audio de los mensajes vocales de los buzones de voz y cambiamos los permisos para usuario y grupo sems:

   

  mkdir -p /var/spool/voicebox

   

  chown sems:sems /var/spool/voicebox

   

  El paso a seguir, antes de iniciar el programa, es crear/modificar el archivo de configuración de SEMS. Renombramos el archivo predefinido:

   

  mv /etc/sems/sems.conf /etc/sems/sems.conf.old

   

  creamos uno nuevo:

   

  nano /etc/sems/sems.conf

   

  donde copiamos las siguientes lineas (Modificar IP con la IP de escucha que quieren utilizar y sip_port con el puerto donde quieren ponerse a la escucha). Leer atentamente todos los comentarios presentes):

   

  # IP de escucha. Modificar IP con la IP de escucha de su servidor

  sip_ip=IP

  # Puerto de escucha

  sip_port=5060

  # Carpeta donde se encuentran todos los modulos de SEMS compilados

  plugin_path=/usr/local/lib/sems/plug-in/

  # Se cargaran solamente los modulo declarados en la linea load_plugins

  load_plugins=wav;speex;gsm;conference;echo.so;voicemail;voicebox;msg_storage

  # En este campo se configura que aplicacion se ejecutara para las llamadas entrantes:

  # $(ruri.user) se utilizara la parte usuario de la Request-URI. Ej. sip:voicemail@dominio.org

  # $(ruri.param) se utilizara el parametro app si presente en la Request-URI

  # $(apphdr) se utilizara el valor contenido en la cabecera P-App-Name

  # $(mapping) las aplicaciones se configuraran en el archivo

  # app_mapping.conf utilizando expresiones regulares

  application = $(apphdr)

  # Carpeta donde estan presentes los archivo de configuracion de los modulos

  plugin_config_path=/etc/sems/etc/

  # SEMS se ejecutara en segundo plano

  fork=yes

  # No se enviaran los errores a la salida estandar de Linux

  stderr=no

  # Nivel de LOG

  # 2 INFO

  # 3 DEBUG

  loglevel=3

  # Salida de LOG que luego se configurara en Rsyslog

  syslog_facility=LOCAL2

  # Configuracion para guardar en los registros de LOG cada actividad del servidor

  log_sessions=yes

  log_events=yes

  # Este parametro fija un limite de solicitudes que se aceptan por segundo

  # Se ese limite se supera, el servidor contestara con un 503 Server overload

  cps_limit="10;503;Server overload"

  # Que nombre aparecera en la cabecera User-Agent de los mensajes SIP enviados por SEMS

  signature="SEMS Media Server 1.7"

   

  Guardamos los cambios y configuramos Rsyslog para que los registros de LOG de SEMS se guarden en un archivo dedicado:

   

  nano /etc/rsyslog.conf

   

  después de esta linea:

   

  local1.* -/var/log/rtpengine.log

   

  añadimos (como configurado en sems.conf):

   

  local2.* -/var/log/sems.log

   

  Guardamos los cambios y creamos el archivo de LOG de SEMS:

   

  touch /var/log/sems.log

   

  Reiniciamos rsyslog:

   

  systemctl restart rsyslog

   

  Ahora configuran los servicios que quieren utilizar y al final inician sems:

   

  systemctl start sems

   

  revisan que esté corriendo:

   

  systemctl status sems

   

  Cualquier problema o modulo que quieran configurar, me comentan.

   

  • SEMS. OpenSIPs
  • Media Server
  • Rocky Linux 9

  Vota el Articulo: 

  VotarGive SEMS está de vuelta – Instalación en Rocky Linux 9 1/5Give SEMS está de vuelta – Instalación en Rocky Linux 9 2/5Give SEMS está de vuelta – Instalación en Rocky Linux 9 3/5Give SEMS está de vuelta – Instalación en Rocky Linux 9 4/5Give SEMS está de vuelta – Instalación en Rocky Linux 9 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

January 29, 2025

• Andrea Sannucci Liberada la versión 6.0 del Proxy SIP Kamailio

  Acaba de ser liberada la versión 6.0 de Kamailio. Una actualización mayor que trae muchas novedades y mejorías. La primera y quizás la más interesantes, es que hay un pasaje en la fase de compilación de las fuentes, de make a cmake. En esta versión es posible utilizar todavía make pero en la versión 6.1 que debería ser liberada el próximo año, el soporte de la compilación con make será eliminado.

   

  Ahora una serie de enlaces importantes:

   

  • las nuevas funcionalidades y módulos que vienen con esta versión: https://www.kamailio.org/w/kamailio-v6.0-0-release-notes/

  • La guía para migrar de la versión 5.8.X a la 6.0 https://www.kamailio.org/w/kamailio-v6.0-0-release-notes/

  • una guía de instalación: https://kamailio.org/docs/tutorials/6.0.x/kamailio-install-guide-git/

  • una guía a la compilación utilizando cmake: https://www.kamailio.org/wikidocs/tutorials/cmake/

  En el próximo Videocurso de Kamailio muy probablemente actualizaré la documentación a esta versión.

   

  • Kamailio
  • Proxy SIP

  Vota el Articulo: 

  VotarGive Liberada la versión 6.0 del Proxy SIP Kamailio 1/5Give Liberada la versión 6.0 del Proxy SIP Kamailio 2/5Give Liberada la versión 6.0 del Proxy SIP Kamailio 3/5Give Liberada la versión 6.0 del Proxy SIP Kamailio 4/5Give Liberada la versión 6.0 del Proxy SIP Kamailio 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

January 20, 2025

• Andrea Sannucci Curso OpenSIPs Cluster y Alta Disponibilidad en Amazon AWS

  Después de pensarlo detenidamente y mirar las distintas configuraciones que se podían añadir a la documentación del curso anterior, he decidido ofrecer una nueva edición del curso de OpenSIPs Cluster que tendrá inicio el próximo 17 de febrero 2025. En este curso los cambios más considerables son:

   

  • ampliación del contenido del cifrado de la señalización SIP TLS y del flujo media permitiendo llamadas UDP → TLS y TLS → UDP

  • Nuevo documento dedicado a la configuración WebRTC en OpenSIPs con llamadas de tipo UDP → WSS y WSS → UDP

  • Captura de la señalización SIP cifrada con SNGREP

  • utilizo de servidores EC-2 hospedados en AWS Cloud Computing. Esto permitirá una completa implementación del alta disponibilidad utilizando Keepalived y Corosync/Pacemaker. La configuración aprovechará al máximo la consola linux de AWS

  • configuración inicial y instalación de OpenSIPs en Debian 12

   

  Otra consideración que tuve en cuenta, fue dar la posibilidad a las personas interesadas solamente en los contenidos de poder acceder a ellos a un precio más económico.

   

  A seguir algunos datos que espero sean de utilidad para que puedan ponderar si este curso es de su interés.

   

  Requisitos para inscribirse:

   

  • conocimientos básicos de Linux (distribución Rocky Linux/Almalinux)

  • acceso a Internet de banda ancha

  • conocimientos básicos protocolo SIP (RFC3261)

  ¿Que Aprenderé?

   

  • Preparación del Servidor Linux con Rocky Linux 9/Debian 12

  • Instalación OpenSIPs 3.4.10 o superior

  • OpenSIPs como Registrar - Mid Registrar – Federated User Location Cluster

  • OpenSIPs y llamadas entre extensiones locales y remotas

  • Resolver problemas de NAT (audio de las llamadas y señalización)

  • OpensSIPs para Presencia y mensajes instantáneos - Cluster de presencia

  • OpenSIPs en un entorno multi-dominio

  • Configurar y utilizar Gateway VoIP para llamadas salientes – módulos LOAD_BALANCER, DROUTING junto a QROUTING, en Cluster y el modulo DISPATCHER

  • Recibir llamadas de números geográficos y transferirlas a las extensiones configuradas en OpenSIPs

  • Configurar el cifrado del protocolo SIP y del Flujo media y configurar llamadas de tipo UDP → TLS y TLS → UDP

  • configurar el protocolo WebRTC y realizar llamadas WSS → UDP y UDP → WSS

  • Integrar OpenSIPs con un media server para conferencias audio, correo de voz y test de echo

  • Configurar dos servidores OpenSIPs en alta disponibilidad con Keepalived y Corosync/Pacemaker en servidores EC-2 de Amazon

  • Gestionar y configurar OpenSIPs desde una interfaz Web (OpenSIPs Console)

  • Monitoreo y puesta en seguridad del Servidor Linux y de OpenSIPs

  ¿Cómo funciona?

   

  El curso se divide en 4 módulos semanales. Cada estudiante podrá acceder al campus las 24 horas y ir desarrollando las tareas programadas. El curso es muy practico y cada guía incluye siempre una parte teórica y una practica. Las guías tienen una secuencia lógica y NO ES POSIBLE saltar de una a otra.

   

  Cada lunes, a las 2pm hora de Colombia, tendrá lugar una videoconferencia. Los temas abordados en cada videoconferencia serán:

   

  • Presentación del curso y Protocolo SIP

  • OpenSIPs como una PBX

  • Balanceamiento de Carga, cluster de servidores y Alta disponibilidad

  • Consola Web de OpensIPs

  ¿Cuanto cuesta?

   

  El valor del curso es de 250 dólares, 245 Euros o 1.050.000 pesos colombianos. Para aquellos que necesiten factura hay que añadir, al valor del curso, el 19% de IVA.

   

  Descuentos:

   

  • 10% para pronto pago si te inscribes antes del 9 de Febrero de 2025

  • 15% para empresas que inscriban 3 o más empleados

  • 20% para antiguos estudiantes es decir personas que ya han participado en un curso organizado por VozToVoice

  IMPORTANTE: los descuentos no son acumulables

   

  IMPORTANTE: ofrecemos la posibilidad de inscribirse en la modalidad de sola acceso a los materiales cuyo costo es de 150 dólares, 145 Euro o 650.000 pesos colombianos. Al momento de rellenar el formulario de inscripción, escojan esa modalidad (MATERIALES). A esta modalidad no se aplican Descuentos

   

  Cupos Disponibles:

   

  • 8 modalidad completa

  • 10 solo acceso materiales

  Formas de pago:

   

  • Paypal – No Colombia

  • Tarjeta de crédito

  • Transferencia bancaria pesos Colombianos (Bancolombia)

  • Transferencia bancaria Euro SEPA (Europa)

  • Transferencia bancaria Dólar ACH (USA)

  Para la modalidad completa el precio incluye:

   

  • Dos servidores remotos virtuales con IP flotante disponible para toda la duración del curso (4 semanas) hospedados en Amazon AWS

  • Troncales SIP para pruebas de llamadas salientes

  • Un numero geográfico de Estados Unidos para las pruebas de llamadas entrantes

  • Acceso indefinido a los contenidos del curso y eventuales actualizaciones

  • Acceso indefinido a un foro para las preguntas relacionadas con los contenidos del curso

  Al terminar el curso se entregará un certificado de asistencia de 40 horas, respaldado por la empresa

  Mesa Proyectos SAS.

   

  Para inscribirse, rellenen el siguiente formulario. En anexo a esta entrada temario y más informaciones

   

  Adjunto	Tamaño
  programa_curso_opensips_cluster_-_aws_alta_disponibilidad.pdf	119.4 KB

  • OpenSIPs
  • Alta disponibilidad
  • Cluster
  • Proxy SIP

  Vota el Articulo: 

  VotarGive Curso OpenSIPs Cluster y Alta Disponibilidad en Amazon AWS 1/5Give Curso OpenSIPs Cluster y Alta Disponibilidad en Amazon AWS 2/5Give Curso OpenSIPs Cluster y Alta Disponibilidad en Amazon AWS 3/5Give Curso OpenSIPs Cluster y Alta Disponibilidad en Amazon AWS 4/5Give Curso OpenSIPs Cluster y Alta Disponibilidad en Amazon AWS 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

December 16, 2024

• Andrea Sannucci OpenSIPs: captura TLS con los módulos PROTO_HEP y TRACE en SNGREP

  En un precedente articulo hemos visto como realizar la captura del cifrado de la señalización SIP en Kamailio apoyándonos en el modulo SIPTRACE y utilizando SNGREP. En este articulo veremos como realizar la misma operación en OpenSIPs utilizando los módulos PROTO_HEP y SIPTRACE; esto con el objetivo de ver la captura en SNGREP. Este tipo de configuración nos ayudará a realizar DEBUG de la señalización cifrada en OpenSIPs a través de SNGREP. Mano a la obra.

   

  Empezamos con el modulo PROTO_HEP. Para que funcione correctamente hay que indicar un socket nuevo de escucha que en nuestro caso será:

   

  socket=hep_udp:127.0.0.1:6060

   

  Luego en la parte donde se configuran los módulos añadimos:

   

  #### PROTO_HEP Module

  loadmodule "proto_hep.so"

  modparam("proto_hep", "hep_id", "[sngrep] 127.0.0.1:9060; transport=udp; version=3")

  modparam("proto_hep", "homer5_on", 1)

  modparam("proto_hep", "hep_capture_id", 12345)

   

  El significado de cada linea presente en el bloque:

   

  1. Una descripción

  2. se carga el modulo

  3. se indica el nombre del ID ([sngrep]) que luego se utilizará en el modulo TRACER. 127.0.0.1:9060 son la IP y el puerto donde se enviará la captura realizada a nivel de OpenSIPs. Además se utilizar el protocolo de transporte UDP y la versión HEP numero 3

  4. Se indica que se utilizará el método de encapsulamiento de la versión 5 de Homer (texto plano) que es lo que necesitamos para una correcta visualización en SNGREP

  5. Se indica un numero que identifique de manera univoca el nodo (PERSONALIZAR CON UN NUMERO ENTERO DE SU GUSTO)

  Una vez terminada la configuración del modulo PROTO_HEP, podemos pasar a la configuración del modulo TRACER:

   

  #### TRACER Module

  loadmodule "tracer.so"

  modparam("tracer", "trace_on", 1)

  modparam("tracer", "trace_id", "[traceid]uri=hep:sngrep")

   

  El significado de las distintas lineas presentes en el bloque:

   

  1. Una descripción

  2. se carga el modulo

  3. se activa la funcionalidad de captura del modulo

  4. se configura un trace_id que luego se utilizará, a través de la función activada por el modulo, en el script de enrutamiento de OpenSIPs. Después del nombre ([traceid]) se indica que la uri es de tipo hep y que el hombre de la uri es sngrep (el parametro hep_id configurado en el modulo PROTO_HEP).

  Ahora pasamos a la función trace, activada por el modulo TRACER, que se utilizará en el script de enrutamiento de OpenSIPs; su sintaxis es:

   

  trace(trace_id, [scope, [type, [trace_attrs]]])

  • trace_id es el nombre del trace_id configurado como parámetro del modulo. En nuestro caso el nombre es traceid

  • scope es el tipo de captura que se va a realizar; las distintas opciones:

    • m o M capturar los mensajes SIP. La unica opción que se puede utilizar en un escenario donde OpenSIPs está configurado en modo Stateless

    • t o T se capturarán las transacciones

    • d o D se capturarán los dialogos

  • type representa el tipo de mensaje que se van a capturar:

    • sip mensajes SIP

    • xlog mensajes de LOG generados por OpenSIPs

    • rest captura de mensajes de tipo REST

  • trace_attrs un valor o una pseudo variable que luego se puede almacenar en los paquetes capturados.

  En nuestro caso, como queremos capturar todas las transacciones que pasen por OpenSIPs, después de esta linea:

   

  route{

   

  que abre el script de enrutamiento de OpenSIPs, añadimos:

   

  trace("traceid","T","sip");

   

  Guardamos los cambios y reiniciamos OpenSIPs:

   

  systemctl restart opensips

   

  Ahora pasamos a SNGREP, donde para realizar la captura utilizaremos el siguiente comando:

   

  sngrep -l 4000 -R -d lo -Ludp:127.0.0.1:9060

   

  El modulo TRACER activa una serie de comando que se pueden utilizar a través de la consola opensips-cli:

   

  opensips-cli -x mi trace

   

  se utiliza para ver el estado de todos los traceid configurados (ya que se puede configurar más de uno);

   

  opensips-cli -x mi trace mode=off

  opensips-cli -x mi trace mode=on

  opensips-cli -x mi trace mode=off id=traceid

   

  Que se utilizan para apagar la captura, encender la captura, apagar la captura solamente de un determinado traceid respectivamente.

   

  Un ejemplo de captura de registro TLS:

   

  

  Tengo que darle las gracias a la lista de distribución de OpenSIPs y a esta entrada de Blog que me ha ayudado mucho con la configuración.

  • OpenSIPs 3.4
  • PROTO_HEP
  • TRACER
  • SNGREP
  • TLS
  • SIP TLS

  Vota el Articulo: 

  VotarGive OpenSIPs: captura TLS con los módulos PROTO_HEP y TRACE en SNGREP 1/5Give OpenSIPs: captura TLS con los módulos PROTO_HEP y TRACE en SNGREP 2/5Give OpenSIPs: captura TLS con los módulos PROTO_HEP y TRACE en SNGREP 3/5Give OpenSIPs: captura TLS con los módulos PROTO_HEP y TRACE en SNGREP 4/5Give OpenSIPs: captura TLS con los módulos PROTO_HEP y TRACE en SNGREP 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

December 06, 2024

• Andrea Sannucci Cuenta de canales en Kamailio sin y con Parámetros Globales Personalizados

  Dependiendo del escenario, necesitamos contar los canales que cada usuario/cliente está utilizando y al mismo tiempo queremos limitar ese numero de canales fijando un valor valido a nivel global. Claramente esta es solamente una forma de realizar ese tipo de configuración y seguramente la más sencilla ya que no vamos a diferenciar el numero de canales según el cliente. En este articulo veremos dos formas de hacerlo:

   

  1. utilizando un valor que si se modifica obliga a reiniciar el Proxy SIP

  2. utilizando un valor que se puede modificar utilizando el comando kamcmd y el modulo CFG_RPC

  En el primer caso la configuración se realiza de la siguiente manera; se cargan los módulos DIALOG y CFG_RPG de Kamailio:

   

  loadmodule "cfg_rpc.so"

  loadmodule "dialog.so"

   

  y entre los distintos parámetros del modulo DIALOG se añade (en negrita):

   

  # ----- dialog params -----

  modparam("dialog", "enable_stats", 1)

  modparam("dialog", "rr_param", "did")

  modparam("dialog", "timeout_avp", "$avp(dlg_timeout)")

  modparam("dialog", "default_timeout", 21600)

  modparam("dialog", "early_timeout", 300)

  modparam("dialog", "noack_timeout", 30)

  modparam("dialog", "end_timeout", 60)

  modparam("dialog", "dlg_match_mode", 0)

  modparam("dialog", "db_url", DBURL)

  modparam("dialog", "db_mode", 1)

  modparam("dialog", "send_bye", 1)

  modparam("dialog", "profiles_with_value", "canales")

   

  con este parámetro se dice a Kamailio que se va a crear un perfil de diálogos con nombre canales y que este perfil puede manejar valores (contar). Luego en este bloque presente en el archivo predefinido de Kamailio:

   

  if (is_method("INVITE")) {

      setflag(FLT_ACC); # do accounting

  }

   

  se añade la linea en negrita:

   

  if (is_method("INVITE")) {

      setflag(FLT_ACC); # do accounting

      dlg_manage();

  }

   

  que nos permite activar el modulo DIALOG para las llamadas y de este forma a toda una serie di variables y parámetros que se pueden leer o configurar por cada dialogo. Luego en el punto que nos interesa (normalmente antes de sacar llamadas salientes):

   

  if(!($rU=~"^(\+|00)[1-9][0-9]{3,20}$")) return;

   

  se añade esta linea:

   

  route(CANALES);

   

  y normalmente al final del archivo se añade:

   

  route[CANALES] {

      set_dlg_profile("canales","$fU");

      get_profile_size("canales","$fU","$avp(usados)");

      if($avp(usados) > 2) {

         sl_send_reply("503", "Has excedido el limite de canales");

         exit;

      }

  }

   

  Una explicación:

   

  • en la segunda linea se añade el dialogo (llamada) al perfil canales utilizando como referencia el numero de usuario contenido en la variable $fU

  • en la tercera linea se asigna a la variable $avp(usados) el valor del perfil canales para el usuario que está llamando

  • en la cuarta linea se envía la frase que aparece al LOG de Kamailio

  • en la quinta linea si el numero de canales usados por el usuario es más que 2, se continua con la linea que sigue sino se salta el bloque por completo

  • en la sexta linea se envía al LOG de Kamailio un comento notificando que se ha superado el numero de canales disponibles por el usuario contenido en la variable $fU

  • en la séptima linea se envía un mensaje de error SIP 503 indicando que se ha excedido el numero de canales disponibles

   

  En este caso el numero máximo de canales es 2 pero podría ser cualquiera.

   

  El segundo tipo de configuración se basa en los Parámetros Globales Personalizados que tienen la siguiente sintaxis:

   

  group.variable = value desc "description"

   

  si queremos configurar el numero de canales utilizando estos parámetros nada más poner en la parte del archivo de configuración dedicada a los parámetros globales:

   

  canales.num_can = "2" desc "numero de canales"

   

  luego el bloque anterior se modifica para que quede (en negrita los cambios):

   

  route[CANALES] {

      set_dlg_profile("canales","$fU");

      get_profile_size("canales","$fU","$avp(usados)");

      if($avp(usados) > $sel(cfg_get.canales.num_can)) {

         sl_send_reply("503", "Has excedido el limite de canales");

         exit;

      }

  }

   

  Esa variable contendrá el valor 2 presente en la configuración del parámetro global personalizado. Si mientras Kamailio está funcionando queremos cambiar ese valor:

   

  kamcmd cfg.set canales num_can nuevovalor

   

  ejemplo para 10 canales:

   

  kamcmd cfg.set canales num_can 10

   

  si queremos saber en cualquier momento que valor tiene ese parámetro:

   

  kamcmd cfg.get canales num_can

   

  IMPORTANTE: ese valor se mantiene hasta que no se reinicie Kamailio ya que el Proxy a reiniciarse, leerá nuevamente el valor presente en el parámetro global personalizado.

   

  • Kamailio
  • Proxy SIP
  • Cuenta de canales
  • Parámetros Globales Personalizados

  Vota el Articulo: 

  VotarGive Cuenta de canales en Kamailio sin y con Parámetros Globales Personalizados 1/5Give Cuenta de canales en Kamailio sin y con Parámetros Globales Personalizados 2/5Give Cuenta de canales en Kamailio sin y con Parámetros Globales Personalizados 3/5Give Cuenta de canales en Kamailio sin y con Parámetros Globales Personalizados 4/5Give Cuenta de canales en Kamailio sin y con Parámetros Globales Personalizados 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

December 02, 2024

• Andrea Sannucci Amazon Ami Linux, Nagios y el plugin check_nrpe

  Antes de ayer, a lo largo de la configuración de un Nagios con monitoreo de servidores remotos, tenía un problema bastante serio de cifrado que no me permitía, prácticamente, monitorear cualquier servicio remoto. La comunicación entre el servidor Nagios y los servidores remotos es completamente cifrada y se basa en el plugin check_nrpe que permite monitorear cualquier servicio remoto “engañando” Nagios para que piense que el servicio es local.

   

  Hay que subrayar que en la Linux AMI de Amazon Nagios, los plugin y la mayoría de las cosas hay que instalarlas desde las fuentes ya que no se pueden instalar los repositorios epel pues no se puede utilizar toda la paquetería presente en esos repositorios. Entre los plugin que hay que instalar desde las fuentes está check_nrpe imprescindible para el monitoreo de servicios remotos. En este articulo veremos como instalar la ultima versión disponible desde las fuentes con soporte SSL.

   

  wget -O nrpe.tar.gz https://github.com/NagiosEnterprises/nrpe/archive/nrpe-4.1.0.tar.gz

   

  tar -xf nrpe.tar.gz

   

  cd nrpe-nrpe-4.1.0/

   

  IMPORTANTE: configurar el soporte del cifrado

   

  ./configure --enable-ssl

   

  si utilizamos el comando make:

   

  make

   

  nos devolverá:

   

  Please enter make [option] where [option] is one of:

   

  all builds nrpe and check_nrpe

  nrpe builds nrpe only

  check_nrpe builds check_nrpe only

  install-groups-users add the users and groups if they do not exist

  install install nrpe and check_nrpe

  install-plugin install the check_nrpe plugin

  install-daemon install the nrpe daemon

  install-config install the nrpe configuration file

  install-inetd install the startup files for inetd, launchd, etc.

  install-init install the startup files for init, systemd, etc.

   

  como queremos compilar solamente el plugin utilizaremos el comando:

   

  make check_nrpe

   

  luego copiaremos el plugin compilado en la carpeta que contiene todos los plugins de Nagios que he instalado anteriormente desde las fuentes:

   

  cp src/check_nrpe /usr/local/nagios/libexec/

   

  cambiamos los permisos del archivos

   

  chmod +x /usr/local/nagios/libexec/check_nrpe

   

  y luego miramos la sintaxis del plugin:

   

  /usr/local/nagios/libexec/check_nrpe -h

   

  Otra cosa importante que no viene por defecto en la Linux AMI de Amazon, y que me parece un poco absurdo, es rsyslog utilizado para la gestión de los LOG del sistema operativo:

   

  dnf install rsyslog

   

  systemctl enable rsyslog

   

  systemctl start rsyslog

   

  Si les gustaría tener una guía completa de la instalación de Nagios en Ami Linux, me comentan

   

  • Amazon Linux AMI
  • Nagios
  • check_nrpe
  • Rsyslog

  Vota el Articulo: 

  VotarGive Amazon Ami Linux, Nagios y el plugin check_nrpe 1/5Give Amazon Ami Linux, Nagios y el plugin check_nrpe 2/5Give Amazon Ami Linux, Nagios y el plugin check_nrpe 3/5Give Amazon Ami Linux, Nagios y el plugin check_nrpe 4/5Give Amazon Ami Linux, Nagios y el plugin check_nrpe 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

November 26, 2024

• Andrea Sannucci ChatGPT, Kamailio e algunas curiosidades

  Esta mañana, inspirado por el libro “La nueva inteligencia y el contorno de lo humano” che de verdad les animo a leer, he vuelto, después de mucho tiempo, a jugar con ChatCPT. En especifico estaba intentando aclarar el funcionamiento del modulo DMQ acerca de los registros; a lo largo de la conversación, el cachorro me ha salido con esto:

   

  modparam("dmq", "peer_list", "sip:10.0.0.2:5060, sip:10.0.0.3:5060")

  que es un parámetro que en el modulo DMQ no existe. Cuando le he hecho notar che se había equivocado la respuesta ha sido muy interesante:

   

  “Tienes razón, pido disculpas por el error: el parámetro peer_list no existe en el módulo DMQ de Kamailio. La configuración de los peers se produce dinámicamente a través de un mecanismo de detección automática o configuración manual en archivos de configuración. ¡Así que vamos a corregir la parte relacionada con la configuración de peer y profundicemos el funcionamiento correcto!”

   

  Cuando más tarde le he preguntado:

   

  ¿Existe il parámetro peer_list en el modulo DMQ?

   

  Me ha contestado:

   

  “No, el parámetro peer_list no existe en el módulo DMQ de Kamailio. El módulo de cola de mensajes distribuidos (DMQ) maneja la comunicación entre los nodos de un clúster de Kamailio para sincronizar información (como grabaciones SIP, llamadas, etc.) entre nodos. Sin embargo, la configuración de peers y la administración de la comunicación entre nodos no se realiza a través de un parámetro llamado peer_list.”

   

  En otra respuesta me ha devuelto otro parámetro de configuración que no existe así que le comentado:

   

  este parámetro no existe: modparam("usrloc", "use_dmq", 1)

   

  y me ha contestado:

   

  “Tienes razón, te pido disculpas por el error. El parámetro use_dmq no existe en el módulo usrloc. La sincronización de registros con DMQ en Kamailio no se configura directamente a través del módulo usrloc con un parámetro como use_dmq. En cambio, la sincronización de registros entre nodos es administrada por el propio módulo dmq, y la integración entre DMQ y usrloc se realiza automáticamente a través de la infraestructura DMQ. Para configurar Kamailio para sincronizar registros entre nodos, la sincronización de la información de registro ya está habilitada a través del módulo dmq, sin necesidad de configurar parámetros específicos en usrloc.”

   

  donde, si se fijan, ha caído en otro error ya que la sincronización de los registros se apoya en el modulo DMQ_USRLOC

   

  Moraleja: hay que educarlo bien para que luego sepa como ayudarnos con Kamailio

   

  • Kamailio
  • ChatGPT
  • IA
  • AI

  Vota el Articulo: 

  VotarGive ChatGPT, Kamailio e algunas curiosidades 1/5Give ChatGPT, Kamailio e algunas curiosidades 2/5Give ChatGPT, Kamailio e algunas curiosidades 3/5Give ChatGPT, Kamailio e algunas curiosidades 4/5Give ChatGPT, Kamailio e algunas curiosidades 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

November 19, 2024

• Andrea Sannucci Curso Presencial Proxy SIP Kamailio – Bogotá, Colombia – 18-21 Marzo 2025

  Yo creo que este más que un curso de capacitación es un evento. Es un evento porque, hasta donde yo sepa, es el único curso presencial en español dedicado al Proxy SIP Kamailio. Con la pandemia y post pandemia nos acostumbramos a realizar todas las capacitaciones a distancia pero yo creo, a pesar de que siempre he sido “hincha” de los cursos en linea, que los cursos presenciales tienen un proceso de aprendizaje y se pueden apoyar en un estilo didáctico que los cursos a distancia no pueden igualar. Además de eso es un momento único para conocerse, intercambiar y compartir. Es por eso que he decidido realizar este curso presencial en la ciudad de Bogotá en los días 18-21 de Marzo de 2025.

   

  El espacio donde se va a dictar está cerca del parque de la 93 que una zona muy conocida y concurrida de la ciudad de Bogotá. Hay mucha oferta hotelera, restaurantes y locales para salir a tomar algo. La idea es que no tengan que desplazarse con taxi o medios públicos y puedan disfrutar de un paseo para llegar a las instalaciones de Counity que es el centro de Coworking que he escogido como sede del curso.

   

  Por el precio y los contenidos, seguramente el curso está pensado para empresas que quieran capacitar sus trabajadores, aunque está abierto a profesionales independientes y, porque no, puros apasionados del mundo VoIP. Para aquellos que por cualquier motivo no puedan participar, nos podemos ver después de clases, 6pm, para ir a tomar algo en las cercanías de las instalaciones y dedicarnos a charlas amenas.

   

  Gracias a las sugerencias y consejos recibidos en el pasado curso, he decidido bajar considerablemente los precios para darles la oportunidad a más gente de participar. Personalmente creo que, considerando el “producto” de que estamos hablando, el precio está perfectamente en la media de lo que paga una empresa para ese tipo de capacitaciones pero si estoy equivocado, me comentan.

   

  Después de la premisa, unos datos:

   

  Requisitos para inscribirse:

  • conocimientos básicos de Linux (distribución Almalinux/Rocky Linux 64bit)

  • conocimientos básicos protocolo SIP (RFC3261)

  • computadora portátil con instalado un cliente SSH para conexiones a servidores remotos. Si no tienes disponibilidad indicarlo al momento de la inscripción

   

  ¿Que Aprenderé?

   

  • Preparación del Servidor Linux con Rocky Linux 64bit – Versión 9

  • Instalación de la ultima versión de Kamailio disponible de la rama 5.8.X

  • Kamailio como SWITCH de Clase 5:

    • Registro y localización

    • Llamadas entre extensiones

    • Resolver problemas de NAT (señalización y audio de las llamadas)

    • Transcodificación Codec Audio en las llamadas y grabación de las llamadas a través de RTPEngine

    • Presencia y mensajes instantáneos

    • Llamadas entrantes y salientes

    • Servidor media para conferencias audio, correo de voz y test de echo (Asterisk PBX y/o FreeSWITCH)

    • Configurar distintas empresas/clientes en el mismo servidor (Multi dominio)

    • Cifrado señalización SIP y flujo media (TLS y SRTP) y WebRTC

  • Kamailio como balanceador de carga (SWITCH de Clase 4):

    • Protocolo PATH

    • Modulo DISPATCHER (Outbound Proxy y protocolo PATH). Como distribuir todas las solicitudes SIP o solamente las llamadas entre dos servidores Asterisk PBX.

    • Modulo LCR. Distribución de llamadas basadas en prefijos, pesos y prioridades

    • modulo DROUTING. Distribución de llamadas basada en reglas y permisos

  • Kamailio como SBC (Session Border Control)

    • Enmascaramiento de la topología de red

    • Gestión del trafico media

    • trasncoding y puente entre protocolos de transporte

    • Gestión de NAT

    • Control de Acceso

    • Corrección de mensajes SIP con errores

    • Cifrado del flujo media

  • Integración de Kamailio con Asterisk PBX:

    • Autenticación en Kamailio

    • Registro y localización de los dispositivos en Kamailio

    • Llamadas entre extensiones en Asterisk

    • Llamadas entrantes y salientes en Kamailio

    • Servicios Media (IVR, Buzón de voz, etc) en Asterisk

  • Integración de Kamailio con FreeSWITCH:

    • Autenticación en Kamailio

    • Registro y localización de los dispositivos en Kamailio

    • Llamadas entre extensiones en FreeSWITCH

    • Llamadas entrantes y salientes en Kamailio

    • Servicios Media (IVR, Buzón de voz, etc) en FreeSWITCH

  • Conocer como configurar Kamailio en Alta disponibilidad con Keepalived y Corosync/Pacemajer (utilizando servidores de Amazon EC2)

  • Gestionar y configurar Kamailio desde una Consola Web (Siremis)

  • Puesta en seguridad de Kamailio:

    • modulo SANITY

    • modulo PIKE

    • modulo SECFILTER

    • modulo TOPOH

    • modulo TOPOS

    • Fail2BAN

  • Monitoreo de Kamailio:

    • Homer SIP Capture Server

    • MONIT

    • Protocolo SNMP y Nagios

    • Consola Web Siremis

  Numero Máximo de cupos disponibles: 12

   

  ¿Cuanto cuesta?

   

  El valor del curso es de 1000 dólares o 3.000.000 pesos colombianos. Descuentos:

   

  • 10% para pronto pago/inscripción temprana; pagos realizados antes del 28 de Febrero;

  • 15% para empresas que inscriban 3 o más empleados.

  • 20% para antiguos estudiantes que ya participaron en un curso organizado por VozToVoice

  Al terminar el curso se entregará un certificado de asistencia de 30 horas, respaldado por la empresa Mesa Proyectos SAS

   

  Formulario de inscripción.

   

  Hoteles Aconsejados para aquellos que lleguen desde otras ciudades/países:

   

  • Novotel Bogotá - Parque La 93

  • NH Bogotá Pavillon Royal

  • Holiday Inn Express Bogotá – Parque la 93

  • Estelar de la 93

  • Best Western Plus 93 Park Hotel

  Conexiones Aéreas a la ciudad de Bogotá:

   

  • Avianca

  • LATAM Airlines

  • COPA Airlines

  Compañía de bajo costo:

   

  • Wingo

  • JetSmart

  Más informaciones y el temario del curso, lo encuentran en el anexo que viene con esta entrada.

   

  Los espero en Bogotá

   

  Adjunto	Tamaño
  programa_curso_kamailio_-_bogota.pdf	267.03 KB

  • Curso presencial
  • Proxy SIP
  • Kamailio
  • Bogotá

  Vota el Articulo: 

  VotarGive Curso Presencial Proxy SIP Kamailio – Bogotá, Colombia – 18-21 Marzo 2025 1/5Give Curso Presencial Proxy SIP Kamailio – Bogotá, Colombia – 18-21 Marzo 2025 2/5Give Curso Presencial Proxy SIP Kamailio – Bogotá, Colombia – 18-21 Marzo 2025 3/5Give Curso Presencial Proxy SIP Kamailio – Bogotá, Colombia – 18-21 Marzo 2025 4/5Give Curso Presencial Proxy SIP Kamailio – Bogotá, Colombia – 18-21 Marzo 2025 5/5

  Promedio: 5 (1 voto)

  Evalúa la calidad del articulo

  • 
  • 
  • 

November 13, 2024

• Andrea Sannucci Renovar los certificados de Let’s Encrypt utilizando un Temporizador systemd

  Hasta hace poco, para renovar los certificados de Let’s Encrypt utilizaba un cronjob configurado de la siguiente manera:

   

  ##### CertBot

  29 2 15,28 * * /usr/bin/systemctl stop httpd

  30 2 15,28 * * /usr/bin/certbot renew

  35 2 15,28 * * /usr/bin/systemctl start httpd

   

  Cada día 15 y 28 de cada mes, iniciando a las 2:29am paraba el servidor Web, ejecutaba el comando para renovar los certificados y volvía a iniciar el servidor Web.

   

  Hoy, mientras estaba instalando el programa certbot desde los repositorios de Rocky Linux 9, me he fijado en esto:

   

  

  Certbot tiene un servicio/Temporizador que se puede activar para que los certificados se renueven de manera automática sin tener que utilizar script o CronJob. Si miramos el contenido del archivo:

   

  nano /usr/lib/systemd/system/certbot-renew.timer

   

  [Unit]

  Description=This is the timer to set the schedule for automated renewals

   

  [Timer]

  OnCalendar=*-*-* 00/12:00:00

  RandomizedDelaySec=12hours

  Persistent=true

   

  [Install]

  WantedBy=timers.target

   

  Los parámetros importantes son los contenidos en el segundo bloque; con el primero se indica que el comando contenido en el archivo que vamos a ver a seguir, se ejecutará a la medianoche y al mediodía de cada día y que se introducirá, segundo parámetro, un retraso de hasta 12 horas, esto quiere decir que el comando se ejecutará en cualquier momento entre la medianoche y las 11:59am y el mediodía y las 11:59pm. Siguiendo con el segundo archivo:

   

  nano /usr/lib/systemd/system/certbot-renew.service

   

  [Unit]

  Description=This service automatically renews any certbot certificates found

   

  [Service]

  EnvironmentFile=/etc/sysconfig/certbot

  Type=oneshot

  ExecStart=/usr/bin/certbot renew --noninteractive --no-random-sleep-on-renew $PRE_HOOK $POST_HOOK $RENEW_HOOK $DEPLOY_HOOK $CERTBOT_ARGS

   

  se indica que el archivo que contendrá las variables utilizadas por el comando certbot renew es /etc/sysconfig/certbot que a su vez contiene los siguientes parámetros:

   

  PRE_HOOK=""

  POST_HOOK=""

  DEPLOY_HOOK=""

  CERTBOT_ARGS=""

   

  cuyo significado es, respectivamente:

   

  • comando a ejecutar antes de renovar los certificados, ejemplo, parar el servidor Web

  • comando a ejecutar después de renovar los certificados, ejemplo reiniciar el servidor web

  • comando a ejecutar para cada certificado renovado, ejemplo uno script que envía un correo notificando que el certificado se ha renovado

  • cualquier parámetro adicional se quiera añadir al comando certbot renew entre los permitidos

   

  En nuestro caso lo dejamos así:

   

  PRE_HOOK="usr/bin/systemctl stop httpd"

  POST_HOOK="usr/bin/systemctl start httpd"

  DEPLOY_HOOK=""

  CERTBOT_ARGS=""

   

  Luego para iniciar el servicio y que se inicie en automático cada vez que se reinicie el servidor:

   

  systemctl enable certbot-renew.timer

   

  systemctl start certbot-renew.timer

   

  systemctl status certbot-renew.timer

  certbot-renew.timer - This is the timer to set the schedule for automated renewals

  Loaded: loaded (/usr/lib/systemd/system/certbot-renew.timer; enabled; preset: enabled)

  Active: active (waiting) since Wed 2024-11-13 08:22:59 -05; 3s ago

  Until: Wed 2024-11-13 08:22:59 -05; 3s ago

  Trigger: Wed 2024-11-13 14:37:32 -05; 6h left

  Triggers: â certbot-renew.servic

   

  • certbot
  • Let's Encrypt
  • Systemd
  • Temporizador
  • Rocky Linux 9

  Vota el Articulo: 

  VotarGive Renovar los certificados de Let’s Encrypt utilizando un Temporizador systemd 1/5Give Renovar los certificados de Let’s Encrypt utilizando un Temporizador systemd 2/5Give Renovar los certificados de Let’s Encrypt utilizando un Temporizador systemd 3/5Give Renovar los certificados de Let’s Encrypt utilizando un Temporizador systemd 4/5Give Renovar los certificados de Let’s Encrypt utilizando un Temporizador systemd 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

November 11, 2024

• Andrea Sannucci Instalación de Kamailio 5.8 y RTPEngine en Amazon EC2 – Rocky Linux 9

  Esta entrada no va a tener muchas explicaciones para reducir el tamaño y porque en la mayoría de los casos no hacen falta. Una vez creada la Instancia de EC2 con Rocky Linux 9, se accede a ella y:

   

  sudo su

   

  dnf install nano -y

   

  Memoria de SWAP:

   

  dd if=/dev/zero of=/swapfile bs=2040 count=1024k

  mkswap /swapfile

  swapon /swapfile

   

  nano /etc/fstab

   

  /swapfile swap swap defaults 0 0

   

  chmod 0600 /swapfile

   

  dnf install epel-release -y

   

  dnf config-manager --set-enabled crb

  dnf update -y

  dnf install wget git -y

  timedatectl set-timezone America/Bogota

  dnf install chrony -y

  systemctl enable chronyd

  systemctl start chronyd

   

  nano /root/.bash_profile

   

  export EDITOR=/usr/bin/nano

  export PS1='\[\033[0;35m\]\H\[\033[0;33m\] \w\[\033[00m\]: '

  alias free="free -m"

  alias kacfg="nano /etc/kamailio/kamailio.cfg"

  alias kalog="nano /var/log/kamailio.log"

  alias katail="tail -500f /var/log/kamailio.log"

  alias mysql="mysql -u root -pKLuJUE3NEwTaSH6S"

   

  source /root/.bash_profile

   

  nano /etc/selinux/config

   

  dnf update -y

   

  reboot

   

  dnf config-manager --set-enabled crb

   

   

  dnf group install 'Development Tools' -y

   

  dnf install bison-devel mariadb-devel mariadb-server net-tools libgcrypt-devel net-snmp-devel xmlto libmicrohttpd-devel xmlrpc-c-devel lynx \

  libxml2-devel expat-devel ncurses-devel net-snmp net-snmp-devel net-snmp-libs net-snmp-utils jansson-devel pcre-devel \

  libuuid-devel uuid uuid-devel ruby-devel spandsp-devel gperf sqlite sqlite-devel postgresql-devel postgresql-server ngrep \

  lksctp-tools-devel python3-devel libjwt-devel openldap openldap-clients openldap-devel openldap libmemcached-devel systemd-devel \

  unixODBC unixODBC-devel mariadb-connector-odbc libtool-ltdl-devel libtool mono-devel hiredis-devel perl-ExtUtils-Embed libpurple-devel \

  lua-devel libdb-cxx-devel libunistring-devel thrift-devel libevent-devel json-c-devel librabbitmq-devel libmaxminddb-devel bind bind-devel \

  libev-devel libmnl-devel expat-devel libwebsockets-devel iptables-devel iptables-services libpcap-devel json-glib-devel libevent-devel perl-IPC-Cmd \

  kernel-modules-extra pandoc iptables-legacy-devel libnftnl-devel zeromq libavc1394 opus-devel cmake iptables-utils libnl3-devel tcpdump -y

   

  wget -q -O - https://updates.atomicorp.com/installers/atomic | sh

   

  dnf install GeoIP-devel -y

   

  dnf install --nogpgcheck https://mirrors.rpmfusion.org/free/el/rpmfusion-free-release-9.noarch.rpm -y

   

  dnf install ffmpeg ffmpeg-devel libavdevice -y

   

  dnf config-manager --add-repo https://rpm.kamailio.org/centos/kamailio.repo

   

  dnf install kamailio* -y

   

  systemctl enable kamailio.service

   

  nano /etc/kamailio/kamailio.cfg

   

  auto_aliases=no

   

  listen=udp:IP_PRIVADA:5060 advertise IP_ELASTICA:5060

   

  nano /etc/rsyslog.conf

   

  local0.* /var/log/kamailio.log

   

  touch /var/log/kamailio.log

   

  systemctl restart rsyslog

   

  nano /etc/logrotate.d/kamailio

   

  /var/log/kamailio.log {

  missingok

  rotate 7

  daily

  postrotate

  /bin/kill -HUP `cat /var/run/rsyslogd.pid 2>/dev/null` 2>/dev/null || true

  endscript

  }

   

  systemctl enable mariadb

  systemctl start mariadb

  mysqladmin -u root password KLuJUE3NEwTaSH6S

  mysql_secure_installation

   

  Primeras dos preguntas se contesta con NO, las siguientes todas con YES

   

  mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -pKLuJUE3NEwTaSH6S mysql

   

  nano /etc/my.cnf.d/mariadb-server.cnf

   

  default-time-zone = America/Bogota

   

  systemctl restart mariadb

   

  mv /etc/kamailio/kamctlrc /etc/kamailio/kamctlrc.old

   

  nano /etc/kamailio/kamctlrc

   

  SIP_DOMAIN=miodominio.org

  DBENGINE=MYSQL

  DBHOST=localhost

  DBNAME=kamailio

  DBRWUSER=kamailio

  DBRWPW="kamailiorw"

  DBROUSER="kamailioro"

  DBROPW="kamailioro"

  DBROOTUSER="root"

  INSTALL_EXTRA_TABLES=ask

  INSTALL_PRESENCE_TABLES=ask

  INSTALL_DBUID_TABLES=ask

  ALIASES_TYPE="DB"

  FIFOPATH="/var/run/kamailio/kamailio_fifo"

  VERIFY_ACL=1

  STORE_PLAINTEXT_PW=0

  PID_FILE=/var/run/kamailio/kamailio.pid

   

  kamdbctl create

   

  MySQL password for root: KLuJUE3NEwTaSH6S

  INFO: test server charset

  INFO: creating database kamailio ...

  INFO: granting privileges to database kamailio ...

  INFO: creating standard tables into kamailio ...

  INFO: Core Kamailio tables succesfully created.

  Install presence related tables? (y/n): y

  INFO: creating presence tables into kamailio ...

  INFO: Presence tables succesfully created.

  Install tables for imc cpl siptrace domainpolicy carrierroute

  drouting userblacklist htable purple uac pipelimit mtree sca mohqueue

  rtpproxy rtpengine secfilter? (y/n): y

  INFO: creating extra tables into kamailio ...

  INFO: Extra tables succesfully created.

  Install tables for uid_auth_db uid_avp_db uid_domain uid_gflags

  uid_uri_db? (y/n): y

  INFO: creating uid tables into kamailio ...

  INFO: UID tables succesfully created.

   

  cd /usr/src

  git clone https://github.com/BelledonneCommunications/bcg729.git

  cd bcg729/

  cmake .

  make

  make install

   

  cd /usr/src

  git clone -b mr12.4 https://github.com/sipwise/rtpengine.git

  cd /usr/src/rtpengine/daemon

  make

  cp rtpengine /usr/local/bin/

  cd /usr/src/rtpengine/kernel-module

  make

   

  uname -r

  5.14.0-427.42.1.el9_4.x86_64

   

  cp xt_RTPENGINE.ko /lib/modules/5.14.0-427.42.1.el9_4.x86_64/extra/xt_RTPENGINE.ko

   

  nano /etc/modules-load.d/rtpengine.conf

   

  xt_RTPENGINE

   

  depmod -a

  modprobe xt_RTPENGINE

  echo 'add 0' > /proc/rtpengine/control

  rtpengine --codecs

   

  cd /usr/src

  git clone -b 2.1-config https://github.com/etamme/federated-sip.git

  cd federated-sip/scripts

  cp rtpengine.service /etc/systemd/system/

  systemctl enable rtpengine.service

  mkdir -p /var/spool/rtpengine

  cp rtpengine.sysconfig /etc/sysconfig/rtpengine

   

  nano /etc/sysconfig/rtpengine

   

  OPTIONS="--interface=pub/IP_PRIAVADA!IP_ELASTICA -n 127.0.0.1:2223 -m 20000 -M 30000 -L 7 --log-facility=local1 --table=0 --nftables-chain="

   

  nano /etc/rsyslog.d/rtpengine.conf

   

  :programname, startswith, "rtpengine" -/var/log/rtpengine.log

   

  & ~

   

  touch /var/log/rtpengine.log

  systemctl restart rsyslog

  systemctl start rtpengine

  nano /etc/logrotate.d/rtpengine

   

  /var/log/rtpengine.log {

  missingok

  rotate 7

  daily

  postrotate

  /bin/kill -HUP `cat /var/run/rsyslogd.pid 2>/dev/null` 2>/dev/null || true

  endscript

  }

   

  cd /usr/src/rtpengine/recording-daemon/

  make

  cp rtpengine-recording /usr/local/bin/

  nano /etc/systemd/system/rtpengine-recording.service

   

  [Unit]

  Description=NGCP RtpEngine - RTP Recording Daemon

  Wants=network-online.target

  After=network-online.target

   

  [Service]

  Type=forking

  Environment=CFGFILE=/etc/rtpengine-recording.conf

  EnvironmentFile=/etc/sysconfig/rtpengine-recording

  PIDFile=/var/run/rtpengine-recording.pid

  ExecStart=/usr/local/bin/rtpengine-recording --config-file=${CFGFILE} --pidfile=/var/run/rtpengine-recording.pid

  Restart=on-failure

   

  [Install]

  WantedBy=multi-user.target

   

  systemctl enable rtpengine-recording

  nano /etc/rtpengine-recording.conf

   

  [rtpengine-recording]

  table = 0

  output-format = wav

  spool-dir = /var/spool/rtpengine

  output-dir = /tmp

  resample-to = 8000

  output-mixed = true

  output-single = false

   

  nano /etc/sysconfig/rtpengine-recording

   

  SET_USER=root

  SET_GROUP=root

   

  kamailio -c /etc/kamailio/kamailio.cfg

  systemctl start kamailio

  nano /var/log/kamailio.log

  kamailio -V

  version: kamailio 5.8.2 (x86_64/linux) 3fa5f4

   

  • Kamailio 5.8
  • RTPEngine
  • Amazon EC2
  • Rocky Linux 9

  Vota el Articulo: 

  VotarGive Instalación de Kamailio 5.8 y RTPEngine en Amazon EC2 – Rocky Linux 9 1/5Give Instalación de Kamailio 5.8 y RTPEngine en Amazon EC2 – Rocky Linux 9 2/5Give Instalación de Kamailio 5.8 y RTPEngine en Amazon EC2 – Rocky Linux 9 3/5Give Instalación de Kamailio 5.8 y RTPEngine en Amazon EC2 – Rocky Linux 9 4/5Give Instalación de Kamailio 5.8 y RTPEngine en Amazon EC2 – Rocky Linux 9 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

November 07, 2024

• Andrea Sannucci ProtonMail – El salva vida de su privacidad

  He hablado del servicio de Proton Mail en otra ocasión cuando estaba teniendo problemas sobre todo con Gmail y en parte con Hotmail. Hoy, de pura casualidad ,volví a entrar a mi cuenta, que por ahora no utilizo mucho ya que tengo mis propios servidores de correo electrónico, y me enteré que hay una oferta que con un dólar permite tener acceso a este plan:

   

  

   

  Aunque el descuento es valido solamente para un mes, es una buena oportunidad para probarlo, sobre todo el tema del dominio que se puede asociar a la cuenta. De hecho he comprado un dominio cualquiera, por un dólar y 16 céntimos para poder realizar la prueba. Personalmente, desde hace mucho (2017), utilizo Namecheap y nunca he tenido problemas. Es fiable y barato. Una vez adquirido el dominio he cambiado la configuración del DNS para que apunte a Linode:

   

  

   

  luego he añadido el dominio en Proton Mail, donde te guían paso paso para la configuración. El resultado final es tener hasta 10 direcciones de correo electrónico con tu propio dominio. El precio real es de 4 dólares y 99 céntimos que no me parece caro considerando los altos estandartes de seguridad y privacidad de esta empresa suiza. Algunos pantallazos del proceso de configuración del dominio:

   

  

   

   

  Para verificar el dominio hay que crear una entrada de tipo TXT (en mi caso en Linode) con los datos indicados en:

   

  

   

  Hay que esperar un par de horas para realizar la verificación; si todo sale bien se continua con el proceso de configuración de las entradas DNS facilitadas por Proton Mail que son:

   

  - MX

  - SPF

  - DKIM

  - DMARC

   

  Me comentan

  • Proton Mail
  • Namecheap
  • Linode
  • privacidad
  • Seguridad
  • DNS

  Vota el Articulo: 

  VotarGive ProtonMail – El salva vida de su privacidad 1/5Give ProtonMail – El salva vida de su privacidad 2/5Give ProtonMail – El salva vida de su privacidad 3/5Give ProtonMail – El salva vida de su privacidad 4/5Give ProtonMail – El salva vida de su privacidad 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

November 06, 2024

• Andrea Sannucci Los COOKIEs en los navegadores pueden ser un hueco sin fin para su correo

  Muchas veces cuando accedemos a nuestro correo electrónico vía Web, tenemos la posibilidad, una vez autenticados, de guardar nuestros datos de registro por un tiempo (normalmente 30 días). De esta forma la sucesiva vez que vamos a entrar, no tenemos que volver a digitar usuario y contraseña. Este tipo de configuración se basa en un ID de sesión que se guarda en un Cookie de sesión que queda en nuestro navegador.

   

  El problema es que es posible que alguien nos robe ese Cookie y de esa forma pueda acceder a nuestro correo electrónico con todo lo que eso comporta. Esto pasa aunque la primera vez que nos autenticamos hemos utilizado un segundo factor de autenticación. ¡Desastre total!

   

  Que podemos hacer para mitigar o eliminar definitivamente el problema:

   

  1. si nos conectamos desde una computadora publica, no utilizar la opción de “Recuerdame”

  2. no utilizar la opción de “Recuerdame” en absoluto

  3. Eliminar todos los Cookies cada vez que se cierre el navegador

   

  La ultima opción es la que yo personalmente utilizo.

   

  En Firefox: Tools → Settings → Privacy & Security:

   

  

   

  En Brave: Configuración → Privacidad y seguridad → Borrar Datos de Navegación:

   

  

   

  No es una tontería. Es importante.

   

  • Cookie
  • eMail

  Vota el Articulo: 

  VotarGive Los COOKIEs en los navegadores pueden ser un hueco sin fin para su correo 1/5Give Los COOKIEs en los navegadores pueden ser un hueco sin fin para su correo 2/5Give Los COOKIEs en los navegadores pueden ser un hueco sin fin para su correo 3/5Give Los COOKIEs en los navegadores pueden ser un hueco sin fin para su correo 4/5Give Los COOKIEs en los navegadores pueden ser un hueco sin fin para su correo 5/5

  Promedio: 5 (2 votos)

  Evalúa la calidad del articulo

  • 
  • 
  • 
• Andrea Sannucci Febrero 2025 – Kamailio 6.0.0

  Según acabo de leer en la lista de distribución de los usuarios de Kamailio, el desarrollador principal de Kamailio, Daniel Constantin Mierla, ha ilustrado el camino de la próxima versión mayor de Kamailio, la 6.0.0

   

  • Reunión de los desarrolladores en Dusseldorf, Alemania, los días 19 y 20 de Noviembre 2024

  • Actualización del código

  • Fase de test a partir del mes de diciembre 2024

  • Salida de la nueva versión, entre final de enero 2025 y inicio Febrero 2025

   

  Seguramente un buen estimulo para actualizar cursos, conferencias y entradas en este Blog.

   

  A seguir el mensaje original:

   

  

   

   

  • Kamailio 6.0.0
  • Proxy SIP

  Vota el Articulo: 

  VotarGive Febrero 2025 – Kamailio 6.0.0 1/5Give Febrero 2025 – Kamailio 6.0.0 2/5Give Febrero 2025 – Kamailio 6.0.0 3/5Give Febrero 2025 – Kamailio 6.0.0 4/5Give Febrero 2025 – Kamailio 6.0.0 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

November 04, 2024

• Andrea Sannucci Asterisk PBX 20.X y el CDR (Call Detail Record)

  Desde la versión 20 de Asterisk PBX, el modulo cdr_mysql.so, que se utilizaba para guardar los registros de las llamadas (CDR) en una base de datos, ya no está presente y no se puede utilizar. En su lugar hay que utilizar el modulo cdr_adaptive_odbc.so, modulo que crea una conexión ODBC a la base de datos y la tabla donde se van a guardar los CDR. Aunque su configuración es un poco más complicada, este modulo nos ofrece unas configuraciones interesantes que en el modulo anterior no estaban disponibles. Los pasos a seguir para la configuración son:

   

  • crear la base de datos y la tabla donde se guardarán los CDR

  • crear una conexión ODBC a la base de datos y la tabla creada

  • configurar el archivo de configuración de Asterisk res_odbc.conf

  • configurar el archivo de configuración de Asterisk cdr_adaptive_odbc.conf

   

  A lo largo de la instalación de Asterisk PBX 20.X presentada en esta entrada, se han instalado y configurado todos los paquetes y módulos que vamos a utilizar para la configuración. Empezamos con la creación de la base de datos. Si no lo hemos hecho, iniciamos MariaDB y creamos una contraseña para el usuario de root:

   

  systemctl start mariadb

   

  systemctl enable mariadb

   

  mysqladmin -u root password AdzyLAR9jQ5zPe4f

   

  entramos con el cliente:

   

  mysql -u root -pAdzyLAR9jQ5zPe4f

   

  creamos la base de datos dedicada solamente a los CDR:

   

  MariaDB [(none)]> create database asteriskcdr;

  Query OK, 1 row affected (0.01 sec)

   

  creamos un usuario que tenga acceso a la base de datos creada:

   

  MariaDB [asteriskcdr]> GRANT ALL PRIVILEGES ON asteriskcdr.* TO 'asterisk'@'localhost' IDENTIFIED BY 'AdzyLAR9jQ5zPe4f';

   

  y luego creamos la tabla:

   

  MariaDB [(none)]> use asteriskcdr

  Database changed

   

  MariaDB [asteriskcdr]> CREATE TABLE cdr (

  id bigint(20) NOT NULL auto_increment,

  accountcode VARCHAR(80),

  src VARCHAR(80),

  dst VARCHAR(80),

  dcontext VARCHAR(80),

  clid VARCHAR(80),

  channel VARCHAR(80),

  dstchannel VARCHAR(80),

  lastapp VARCHAR(80),

  lastdata VARCHAR(80),

  start DATETIME,

  answer DATETIME,

  end DATETIME,

  duration INTEGER,

  billsec INTEGER,

  disposition VARCHAR(45),

  amaflags VARCHAR(45),

  userfield VARCHAR(256),

  uniqueid VARCHAR(150),

  linkedid VARCHAR(150),

  peeraccount VARCHAR(80),

  sequence INTEGER,

  PRIMARY KEY (`id`),

  KEY callerid (clid)

  );

   

  El paso a seguir es crear la conexión ODBC; miramos si el archivo /etc/odbcinst.ini contiene este bloque:

   

  [MariaDB]

  Description = ODBC for MariaDB

  Driver = /usr/lib/libmaodbc.so

  Driver64 = /usr/lib64/libmaodbc.so

  FileUsage = 1

   

  si así fuera seguimos con la configuración de la conexión ODBC:

   

  nano /etc/odbc.ini

   

  [asteriskcdr]

  Driver = MariaDB

  Database = asteriskcdr

  Server = localhost

  User = asterisk

  Password = AdzyLAR9jQ5zPe4f

  Port = 3306

  Option = 3

   

  Se pone el nombre de la base de datos y el usuario que tiene acceso a ella. La etiqueta inicial la utilizaremos más adelante. Ahora para tener la certeza que la conexión funcione correctamente:

   

  isql asteriskcdr asterisk AdzyLAR9jQ5zPe4f

   

  en orden:

   

  • etiqueta que da inicio al bloque configurado en el archivo odbc.ini

  • nombre del usuario que tiene acceso a la base de datos

  • contraseña del usuario indicado en el parámetro anterior

   

  Si todo sale bien:

   

  +---------------------------------------+

  | Connected! |

  | |

  | sql-statement |

  | help [tablename] |

  | quit |

  | |

  +---------------------------------------+

   

  para salir:

   

  SQL> quit

   

  Se continua con la configuración del archivo res_odbc.conf que es donde se crea la conexión entre Asterisk PBX y ODBC:

   

  nano /etc/asterisk/res_odbc.conf

   

  al final del archivo se añade:

   

  [cdr]

  enabled => yes

  dsn => asteriskcdr

  username => asterisk

  password => AdzyLAR9jQ5zPe4f

  pre-connect => yes

   

  la parte importante es la linea dsn => asteriskcdr que es la linea donde se conecta Asterisk al bloque presente en el archivo odbc.ini cuya etiqueta inicial tiene el mismo nombre (asteriskcdr). Se guardan los cambios y se termina la configuración modificando el archivo cdr_adaptive_odbc.conf:

   

  nano /etc/asterisk/cdr_adaptive_odbc.conf

   

  al final del archivo se añade:

   

  [cdr]

  connection=cdr

  table=cdr

   

  • [cdr]: un nombre que se le asigna a la conexión

  • connection=cdr: en este parámetro hay que poner la etiqueta que define el bloque creado en el archivo res_odbc.conf

  • table=cdr: la tabla MariaDB donde se guardarán los datos

   

  Otras configuraciones que se pueden realizar en este archivo:

   

  • filtrar los datos que se guardarán en la tabla. Ejemplo: si se quieren guardar solamente los CDR de la extensión 1000 se añadirá al bloque la siguiente linea: filter src => 1000

  • si se quieren modificar los nombres de las columnas presentes en la tabla CDR, se crean alias y luego se modifican los nombre en la tabla. Ejemplo: alias dst => destinatario

   

  ¿Interesante verdad?

   

  • Asterisk 20
  • CDR
  • cdr_adaptive
  • cdr_mysql
  • ODBC

  Vota el Articulo: 

  VotarGive Asterisk PBX 20.X y el CDR (Call Detail Record) 1/5Give Asterisk PBX 20.X y el CDR (Call Detail Record) 2/5Give Asterisk PBX 20.X y el CDR (Call Detail Record) 3/5Give Asterisk PBX 20.X y el CDR (Call Detail Record) 4/5Give Asterisk PBX 20.X y el CDR (Call Detail Record) 5/5

  Promedio: 5 (1 voto)

  Evalúa la calidad del articulo

  • 
  • 
  • 

October 24, 2024

• Andrea Sannucci Kamailio TLS/UDP o UDP/TLS – Solucionar problema con el Buzón de voz

  Estaba revisando la documentación del próximo VideoCurso de Kamailio relativa a las llamadas TLS/UDP y UDP/TLS, es decir la posibilidad de poder realizar llamadas entre dispositivos que soportan el cifrado de la señalización SIP y del flujo media, y dispositivos que no los soportan. Con esta configuración es posible también utilizar el cifrado de la señalización SIP y del flujo media con base en el dispositivo a que se está llamando.

   

  El único problema que tenía con la configuración actual es que si un dispositivo que no utiliza cifrado de la señalización SIP y del flujo media llama a un dispositivo que soporta el cifrado de la señalización SIP y del flujo media y este ultimo no contesta y/o rechaza la llamada, la llamada llegaba al servidor media (en este caso FREESWITCH) con en el anexo SDP todo lo relacionado con el cifrado del flujo media cuando no debería ser así ya que FS está configurado para aceptar flujo media sin cifrado.

   

  La verdad hace tiempo que intentaba solucionar este problema y no lo lograba, mejor dicho no sabía donde tenía que realizar el cambio y que cambio necesitaba realizar.

   

  Hoy, como siempre pasa con estas cosas, tuve como una “iluminación” y me acordé de una función del modulo COREX que quizás podía servir, append_branch().

   

  Claramente no puedo mostrarles todas la configuración de Kamailio pero el bloque donde realicé la corrección es este:

   

  route[TOVOICEMAIL] {

  #!ifdef WITH_VOICEMAIL

  if(!is_method("INVITE|SUBSCRIBE")) return;

   

  # check if VoiceMail server IP is defined

  if (strempty($sel(cfg_get.voicemail.srv_ip))) {

  xlog("SCRIPT: VoiceMail routing enabled but IP not defined\n");

  return;

  }

  if(is_method("INVITE")) {

  if($avp(oexten)==$null) return;

   

  $ru = "sip:" + $avp(oexten) + "@" + $sel(cfg_get.voicemail.srv_ip)

  + ":" + $sel(cfg_get.voicemail.srv_port);

  } else {

  if($rU==$null) return;

   

  $ru = "sip:" + $rU + "@" + $sel(cfg_get.voicemail.srv_ip)

  + ":" + $sel(cfg_get.voicemail.srv_port);

  }

  append_branch();

  t_on_branch("MANAGE_BRANCH");

  route(RELAY);

  exit;

  #!endif

   

  He añadido las dos lineas en negrita, la primera añade un nuevo branch y la segunda envía la nueva transacción a la ruta de tipo BRANCH con nombre MANAGE_BRANCH. Como ahí es donde se realiza el puente UDP/TLS o TLS/UDP y como la transacción es nueva, se aplicarán todas las correcciones requeridas y la llamada llegara correctamente a FS

   

  Claramente la misma configuración aplica a las llamadas UDP/WebRTC y WebRTC/UDP

   

  Me comentan

   

  • Kamailio
  • TLS
  • SRTP
  • ICE
  • COREX
  • append_branch

  Vota el Articulo: 

  VotarGive Kamailio TLS/UDP o UDP/TLS – Solucionar problema con el Buzón de voz 1/5Give Kamailio TLS/UDP o UDP/TLS – Solucionar problema con el Buzón de voz 2/5Give Kamailio TLS/UDP o UDP/TLS – Solucionar problema con el Buzón de voz 3/5Give Kamailio TLS/UDP o UDP/TLS – Solucionar problema con el Buzón de voz 4/5Give Kamailio TLS/UDP o UDP/TLS – Solucionar problema con el Buzón de voz 5/5

  Promedio: 5 (1 voto)

  Evalúa la calidad del articulo

  • 
  • 
  • 

October 23, 2024

• Andrea Sannucci Curso en linea FreeSWITCH v. 1.10 – Cuarta Edición

  He pensado programar este curso dedicado a FreeSWITCH, que para aquellos que todavía no saben, es una SWITCH/PBX parecido a Asterisk PBX, por dos razones:

   

  • dar la posibilidad a tod@s los inscritos al VideoCurso de Kamailio de profundizar el conocimiento de este programa ya que a lo largo del VideoCurso veremos como integrarlo con Kamailio

  • dar a conocer este programa a aquellos que todavía no lo utilizan porque en cuanto a prestaciones y funcionalidades, supera largamente Asterisk PBX

  Esta, como se lee en el titulo, es la cuarta edición del curso a distancia y sustancialmente los contenidos son los mismos de la tercera edición que tuvo lugar en Junio 2023. A lo largo del curso hablaremos y miraremos las configuraciones para:

   

  • Preparar el Servidor Linux (VPS remoto) con Rocky Linux 8

  • Instalar de FreeSWITCH 1.10.12 o superior desde las fuentes

  • Configurar el cortafuegos

  • Conocer la Arquitectura de FreeSWITCH (Corazón y módulos)

  • Que son y como se configuran los Perfiles SIP

  • Negociación de Codec básica y avanzada

  • Solucionar problemas de NAT

  • Las expresiones regulares utilizadas en el Dialplan (PCRE - Perl Compatible Regular Expressions)

  • Endpoint/Extensiones, Dialplan y Contextos

  • Dialplan básico y avanzado (llamadas entrantes y salientes)

  • Concepto y uso de las Phrase Macros

  • Como utilizar el Buzón de voz

  • Como configurar un IVR

  • Llamadas seguras (TLS, SRTP)

  • Conferencias audio y Videoconferencias

  • WebRTC SIP y VERTO

  • Configuración Multi Dominio, Multi Utente

  • Respaldo de llamadas

  • Monitoreo y seguridad del sistema

  Se ha dejado por fuera la configuración de las colas de espera porque quizás, para este tema, Asterisk PBX está por delante de FreeSWITCH

   

  El Curso iniciará el 18 de noviembre y tendrá una duración de tres semanas, terminando el 8 de diciembre. Cada semana se publicarán guías, videos y tendrá lugar una videoconferencia de una hora/hora y media donde se abordarán todos los temas relacionados con el contenido semanal del curso.

   

  El costo del curso es de 150 dólares, 136 Euros o 650mil pesos colombianos. Descuentos disponibles:

   

  • 10% pronto pago/inscripción temprana; pagos realizados antes del 10 de Noviembre 2024

  • 15% para grupos de 3 o más personas de la misma empresa

  • 20% para inscritos que ya han participado en un curso organizado por VozToVoice

  • participantes VideoCurso de Kamailio: 100 dólares

  El precio incluye:

  • Un servidor remoto para implementar los contenidos de las guías

  • Acceso a los materiales del curso de por vida

  • Una troncal SIP para las llamadas salientes

  • Soporte a través del foro del curso

  • Un numero geográfico de Miami para las pruebas de las llamadas entrantes

  Al terminar el curso se entregará un certificado de asistencia de 30 horas, respaldado por la empresa Mesa Proyectos SAS. Para poder recibir el certificado tendrán que completar por lo menos el 80% de los materiales del curso.

   

  En anexo encuentran el temario. Para inscribirse, rellenen el formulario

   

  Adjunto	Tamaño
  programa_curso_freeswitch.pdf	80.76 KB

  • FreeSWICTH
  • pbx
  • Curso a distancia

  Vota el Articulo: 

  VotarGive Curso en linea FreeSWITCH v. 1.10 – Cuarta Edición 1/5Give Curso en linea FreeSWITCH v. 1.10 – Cuarta Edición 2/5Give Curso en linea FreeSWITCH v. 1.10 – Cuarta Edición 3/5Give Curso en linea FreeSWITCH v. 1.10 – Cuarta Edición 4/5Give Curso en linea FreeSWITCH v. 1.10 – Cuarta Edición 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

October 21, 2024

• Andrea Sannucci Instalación de Asterisk 20.X en Almalinux/RockyLinux 9

  Como ya algunos de ustedes me preguntaron como instalar Asterisk en Almalinux/RockyLinux, he decidido publicar esta guía que se basa en un VPS de Upcloud con instalado Rocky Linux 9. He decidido instalar la versión 20 de Asterisk, que tiene soporte hasta el 19 de octubre del 2027, porque todavía está presente el canal SIP chan_sip, canal que desaparece por completo desde la versión 21.

   

  Una vez creado el servidor se accede vía SSH y se actualiza el sistema:

   

  dnf update -y

   

  se instala el editor nano, la utilizada para comprimir/descomprimir los paquetes y wget que se utilizará para descargar el paquete de Asterisk:

   

  dnf install nano tar wget -y

   

  Como los servidores de UpCloud vienen sin Memoria de Swap, es una buena practica crear una que sea el doble de la memoria RAM disponible; en nuestro caso como la memoria RAM disponible es de 1GB, vamos a crear una memoria de Swap de 2GB:

   

  dd if=/dev/zero of=/swapfile bs=1024 count=2048k

   

  mkswap /swapfile

   

  swapon /swapfile

   

  Se configura la partición de swap para que arranque con el sistema:

   

  nano /etc/fstab

   

  al final del archivo se añade la linea que sigue:

   

  /swapfile swap swap defaults 0 0

   

  Se guardan los cambios y se cambian los permisos del archivo recién creado:

   

  chmod 0600 /swapfile

   

  Se instalan los repositorios de Fedora, una distribución Linux “hermana” de Rocky Linux, que se utilizarán más adelante para instalar algunos paquetes/programas no disponibles en los repositorios estándar de Rocky Linux:

   

  dnf install epel-release -y

   

  Para terminar se revisa si Selinux está activado; si así fuera, se desactiva:

   

  nano /etc/selinux/config

   

  las lineas importantes son:

   

  SELINUX=disabled

  SELINUXTYPE=targeted

   

  Se guardan los cambios y se actualiza nuevamente el sistema:

   

  dnf update -y

   

  Ya se puede reiniciar el servidor remoto:

   

  reboot

   

  Se vuelve a acceder al servidor y se activan los repositorios crb que permiten la instalación de algunos paquetes que no están presentes en los repositorios estándar de Rocky Linux:

   

  dnf config-manager --set-enabled crb

   

  se descarga la ultima versión disponible de la rama 20 de Asterisk:

   

  cd /usr/src/

   

  wget https://downloads.asterisk.org/pub/telephony/asterisk/asterisk-20-curren...

   

  se descomprime:

   

  tar -xf asterisk-20-current.tar.gz

   

  se entra en la carpeta creada:

   

  cd asterisk-20.10.0

   

  se instalan los paquetes requeridos para una correcta compilación de las fuentes:

   

  contrib/scripts/install_prereq install

   

  se entra en el menú de configuración de Asterisk:

   

  make menuselect

   

  si queremos instalar el canal chan_sip (deprecado) entramos en el menú Channel Drivers y lo seleccionamos:

   

  

  En Codec Translators seleccionamos los siguientes módulos:

   

  

  luego en Core Sound Packages y Extra Sound Packages seleccionamos todas los paquetes de las locuciones audio que necesitamos y hacemos lo mismo en Music On Hold File Packages para la música de espera. Terminamos utilizando la tecla tabulador hasta posicionarnos en:

   

  

   

  y presionamos la tecla envío. Luego compilamos:

   

  make

   

  instalamos Asterisk:

   

  make install

   

  instalamos todos los archivos de configuración predefinidos con el comando:

   

  make samples

   

  para que el sript de arranque funcione correctamente:

   

  dnf install chkconfig initscripts -y

   

  con el comando que sigue se instala el script de arranque de Asterisk que permitirá iniciar la PBX al boot de Linux:

   

  make config

   

  Para terminar, si se quiere utilizar el canal chan_sip en lugar de chan_pjsip, se abre el archivo donde se configura todo lo relacionado con los módulos de Asterisk PBX:

   

  nano +48 /etc/asterisk/modules.conf

   

  se modifica el contenido de la linea 48:

   

  noload = chan_sip.so

   

  con:

   

  noload = chan_pjsip.so

   

  se guardan los cambios y se inicia Asterisk:

   

  service asterisk start

  Reloading systemd: [ OK ]

  Starting asterisk (via systemctl): [ OK ]

   

  Lo primero es revisar los LOG para ver si hay errores presentes; en mi caso:

   

  [Oct 19 23:51:28] ERROR[58120] res_config_ldap.c: No directory URL or host found.

  [Oct 19 23:51:28] ERROR[58120] res_config_ldap.c: Cannot load LDAP RealTime driver.

  [Oct 19 23:51:28] ERROR[58120] res_config_pgsql.c: PostgreSQL RealTime: Failed to connect database asterisk on 127.0.0.1:

  [Oct 19 23:51:28] ERROR[58120] res_sorcery_config.c: Contents of config file 'geolocation.conf' are invalid and cannot be parsed

  [Oct 19 23:51:28] ERROR[58120] res_sorcery_config.c: Contents of config file 'geolocation.conf' are invalid and cannot be parsed

  [Oct 19 23:51:29] ERROR[58120] ari/config.c: No configured users for ARI

  [Oct 19 23:51:29] ERROR[58120] loader.c: Failed to resolve dependencies for res_pjsip_geolocation

  [Oct 19 23:51:29] ERROR[58120] loader.c: res_pjsip_geolocation declined to load.

  [Oct 19 23:51:29] ERROR[58120] loader.c: res_pjsip_transport_websocket declined to load.

  [Oct 19 23:51:29] ERROR[58120] loader.c: cdr_pgsql declined to load.

  [Oct 19 23:51:29] ERROR[58120] loader.c: cdr_radius declined to load.

  [Oct 19 23:51:29] ERROR[58120] loader.c: cdr_sqlite3_custom declined to load.

  [Oct 19 23:51:29] ERROR[58120] loader.c: cdr_tds declined to load.

  [Oct 19 23:51:29] ERROR[58120] loader.c: cel_radius declined to load.

  [Oct 19 23:51:29] ERROR[58120] loader.c: cel_sqlite3_custom declined to load.

  [Oct 19 23:51:29] ERROR[58120] loader.c: cel_tds declined to load.

   

  La mayoría de los errores no afecta el correcto funcionamiento de Asterisk ya que están relacionados con módulos que normalmente no se utilizan. Para acceder a la consola de Asterisk:

   

  asterisk -rvvvvvvvvvvvvvv

   

  para salir:

   

  asterisk20*CLI> quit

   

  para ver la versión exacta instalada:

   

  asterisk -V

  Asterisk 20.10.0

   

  En un próximo articulo veremos como configurar el CDR en una base de datos ya que no se puede utilizar más el modulo cdr_mysql.so porque no presente en las fuentes de Asterisk.

   

  Cualquier cosa me comentan

   

   

  • Asterisk PBX 20
  • Almalinux 9
  • Rocky Linux 9

  Vota el Articulo: 

  VotarGive Instalación de Asterisk 20.X en Almalinux/RockyLinux 9 1/5Give Instalación de Asterisk 20.X en Almalinux/RockyLinux 9 2/5Give Instalación de Asterisk 20.X en Almalinux/RockyLinux 9 3/5Give Instalación de Asterisk 20.X en Almalinux/RockyLinux 9 4/5Give Instalación de Asterisk 20.X en Almalinux/RockyLinux 9 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

October 02, 2024

• Andrea Sannucci UpCloud – Buen Proveedor de VPS a buen precio para desarrollo

  Desde hace un tiempo estoy utilizando también este proveedor de VPS finlandés porque hasta el momento me ha funcionado bastante bien. Tiene centros de datos en Europa, Australia, Singapur y USA, cosa que lo hace bastante interesante desde el punto de vista de la latencia y accesibilidad.

   

  Desde hace poco ha lanzado una nueva oferta para desarrolladores que hasta donde yo sepa, es la más económica que hay en el mercado:

   

  • CPU Core: 1

  • Memoria: 1 GB

  • Disco duro: 10 GB

  • IPv4 Publico y Privado

  • IPv6

  • Soporta la Mayoría de las distribuciones Linux, entre las cuales, Almalinux, Debian, Ubuntu, Windows Server

   

  El costo de este servidor es de 3 Euros/Mes y aunque el espacio disco es bastante reducido, es suficiente para realizar pruebas, tener servidores de laboratorio y realizar la mayoría de operaciones que preceden la puesta en producción de un producto.

   

  Otras cosas interesantes es que soporta también otros productos a un precio asequible:

   

  • IP Flotante (estoy investigando como integrar KeepAlived para alta disponibilidad)

  • Balanceamiento de carga

  • Kubernetes

  • Terraform

  • Object Storage

   

  Personalmente les aconsejo probarlo y si lo quieren hacer pueden utilizar este enlace que me permite considerarlos como mis referidos y recibirían un bono de 25 Euros para probar el servicio una vez que registren un método de pago. El periodo de prueba tendrá una duración de 3 días y, creo, que una vez que realicen el primer pago, el valor, mínimo 10 Euros, se sumará a los 25 Euros iniciales. Les agradezco que me comenten sino fuera así.

   

  Me cuentan

   

  • UpCloud
  • vps
  • Desarrollo

  Vota el Articulo: 

  VotarGive UpCloud – Buen Proveedor de VPS a buen precio para desarrollo 1/5Give UpCloud – Buen Proveedor de VPS a buen precio para desarrollo 2/5Give UpCloud – Buen Proveedor de VPS a buen precio para desarrollo 3/5Give UpCloud – Buen Proveedor de VPS a buen precio para desarrollo 4/5Give UpCloud – Buen Proveedor de VPS a buen precio para desarrollo 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

October 01, 2024

• Andrea Sannucci Kamailio modulo DIALOG: el parametro DLG_FLAG ha sido eliminado

  A pesar de que el parámetro DLG_FLAG, del modulo DIALOG, había sido declarado obsoleto desde el 2021, nadie se había tomado el tiempo de actualizar el código; esto hasta hace un mes. El problema del parámetro DLG_FLAG era que si utilizado en el script de routing no almacenaba correctamente las variables relacionadas con las funciones UAC_REPLACE_FROM del modulo UAC, cosa que si se almacenaba correctamente utilizando la función DLG_MANAGE.

   

  Gracias a esta PULL REQUEST, presente en la pagina GITHUB del proyecto, el código ha sido actualizado. Los módulos cuya documentación ha sido modificada son:

   

  • ACC

  • CALL_CONTROL

  • CNXCC

  • DIALOG

  • MEDIAPROXY

  • NAT_TRAVERSAL

  • PUA_DIALOGINFO

  • QOS

  • SST

   

  Los módulos cuyo código ha sido actualizado:

   

  • CALL_CONTROL

  • CNXCC

  • DIALOG

  • MEDIAPROXY

  • NAT_TRAVERSAL

   

  En todos los módulos indicados NO UTILIZAR más el parámetro DLG_FLAG sino el parámetro DLG_MANAGE como indicado en las respectivas documentaciones de los módulos afectados.

   

  Me comentan

   

  • Kamailio
  • DIALOG
  • DLG_FLAG
  • DLG_MANAGE

  Vota el Articulo: 

  VotarGive Kamailio modulo DIALOG: el parametro DLG_FLAG ha sido eliminado 1/5Give Kamailio modulo DIALOG: el parametro DLG_FLAG ha sido eliminado 2/5Give Kamailio modulo DIALOG: el parametro DLG_FLAG ha sido eliminado 3/5Give Kamailio modulo DIALOG: el parametro DLG_FLAG ha sido eliminado 4/5Give Kamailio modulo DIALOG: el parametro DLG_FLAG ha sido eliminado 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

September 30, 2024

• Andrea Sannucci Primer VideoCurso dedicado al Proxy SIP Kamailio

  CUPOS AGOTADOS

   

  Después de Hablarlo en el canal Telegram de VozToVoice, ha llegado el momento del primer VideoCurso dedicado al Proxy SIP Kamailio. Este VideoCurso está compuesto por 6 Videoconferencias de la duración de 4 horas cada una que se dictarán en las siguientes fechas y horas:

   

  • 29 Octubre 2pm hora de Colombia: Presentación del curso, presentación del protocolo SIP, instalación de Kamailio y primera configuración

  • 30 Octubre 2 pm hora de Colombia: Kamailio como una PBX; llamadas entre extensiones, NAT y RTPEngine, llamadas entrantes/salientes, presencia, configuración multitenant multidominio, Servidor Media Asterisk PBX o FreeSWITCH y integración completa entre Kamailio y Asterisk PBX o FreeSWITCH; transcoding y grabación de llamadas con RTPEngine

  • 31 Octubre 2pm hora de Colombia: Kamailio como Redirect Server, Balanceo de Solicitudes SIP y llamadas a través de distintos módulos (DISPATCHER, LCR,DROUTING)

  • 5 Noviembre 2 pm hora de Colombia: Kamailio y el cifrado de las señalización SIP y del flujo media (TLS, SRTP); Kamailio y WebRTC

  • 6 Noviembre2 pm hora de Colombia: Seguridad, Monitoreo y Consola Web de Kamailio, Siremis

  • 7 Noviembre 2pm Kamailio: Teoría y practica del alta disponibilidad utilizando KeepAlived y documentando como se realiza con Pacemaker y Corosync

   

  El objetivo es realizar un camino de aprendizaje que les permita adquirir los siguientes conocimientos:

   

  • Preparación del Servidor Linux con Rocky Linux 64bit – Versión 9

  • Instalación de la ultima versión disponible de Kamailio de la rama 5.8

  • Kamailio como PBX (SWITCH de Clase 5):

    • Registro y localización

    • Llamadas entre extensiones, llamadas secuenciales, llamadas a grupos de dispositivos registrados con las mismas credenciales

    • Resolver problemas de NAT (señalización y audio de las llamadas) utilizando un Media Proxy (RTPEngine)

    • Transcodificación Codec Audio en las llamadas y grabación de las llamadas a través de RTPEngine

    • Presencia y mensajes instantáneos

    • Llamadas entrantes desde números geográficos y salientes con troncales SIP

    • Instalación y configuración de un Servidor media para servicios media: conferencias audio, correo de voz y test de echo utilizando Asterisk PBX o FreeSWITCH)

    • Configurar distintas empresas/clientes en el mismo servidor (Multi dominio)

    • Cifrado señalización SIP y flujo media (TLS y SRTP) y WebRTC

    • Llamadas SIP-TLS y TLS-SIP; llamadas SIP-WebRTC – WebRTC-SIP

  • Kamailio como balanceador de carga (SWITCH de Clase 4):

    • Modulo DISPATCHER (Outbound Proxy y protocolo PATH). Como distribuir todas las solicitudes SIP o solamente las llamadas entre dos servidores Asterisk PBX.

    • Modulo LCR. Distribución de llamadas basadas en prefijos, pesos y prioridades

    • modulo DROUTING. Distribución de llamadas basada en reglas y permisos

  • Integración de Kamailio con Asterisk PBX:

    • Autenticación en Kamailio

    • Registro y localización de los dispositivos en Kamailio

    • Llamadas entre extensiones en Asterisk

    • Llamadas entrantes y salientes en Kamailio

    • Servicios Media (IVR, Buzón de voz, etc) en Asterisk

  • Integración de Kamailio con FreeSWITCH:

    • Autenticación en Kamailio

    • Registro y localización de los dispositivos en Kamailio

    • Llamadas entre extensiones en FreeSWITCH

    • Llamadas entrantes y salientes en Kamailio

    • Servicios Media (IVR, Buzón de voz, etc) en FreeSWITCH

    • Configuración multidominio

  • Conocer como configurar Kamailio en Alta disponibilidad con Keepalived o Pacemaker y Corosync

  • Gestionar y configurar Kamailio desde una Consola Web (Siremis)

  • Puesta en seguridad de Kamailio:

    • modulo SANITY

    • modulo PIKE

    • modulo SECFILTER

    • modulo TOPOH

    • modulo TOPOS

    • Fail2BAN

    • Cuenta de canales

    • RATELIMIT

  • Monitoreo de Kamailio:

    • Homer SIP Capture Server

    • MONIT

    • Protocolo SNMP y Nagios

   

  Además de eso, durante cada videoconferencia será posible probar las configuraciones gracias a la participación activa de los inscritos. De esta forma será posible, cosa muy importante, mostrar que todas las configuraciones funcionan realmente y de la forma esperada.

   

  El costo del VideoCurso es de 300 dólares y hay los siguientes descuentos disponibles:

   

  • 10% para pronto pago/inscripción temprana; pagos realizados antes del 21 de Octubre;

  • 15% para empresas que inscriban 3 o más empleados.

  • 25% para antiguos estudiantes que ya participaron en un curso organizado por VozToVoice

   

  Además de las videoconferencias, será posible acceder a los contenidos del curso a través del Campus de VozToVoice donde se guardarán las grabaciones de las videoconferencias y todos los materiales utilizados para realizar las distintas configuraciones. Para que el proceso de aprendizaje sea el más completo posible, cada participante tendrá disponible:

   

  • Un VPS (servidor virtual privado) para poder poner en practica las configuraciones ilustradas durante las videoconferencias. El servidor estará disponible desde el 27 de Octubre hasta el 30 de noviembre

  • Acceso a llamadas VoIP salientes que se realizarán a lo largo del curso

  • El alquiler de un numero geográfico de Estados Unidos para las pruebas de llamadas entrantes

   

  Creo que va a ser una buena opción de aprendizaje pero serán ustedes que al final juzgarán. Para inscribirse rellenen el formulario presente en esta pagina y o participen activamente en el grupo de Telegram para mejorar el desarrollo del VideoCurso. En anexo temario e informaciones relacionadas con el curso. ¡Gracias!

   

  Adjunto	Tamaño
  programa_videocurso_kamailio.pdf	92.13 KB

  • Kamailio
  • Asterisk PBX
  • FreeSWITCH
  • Proxy SIP
  • VideoCurso

  Vota el Articulo: 

  VotarGive Primer VideoCurso dedicado al Proxy SIP Kamailio 1/5Give Primer VideoCurso dedicado al Proxy SIP Kamailio 2/5Give Primer VideoCurso dedicado al Proxy SIP Kamailio 3/5Give Primer VideoCurso dedicado al Proxy SIP Kamailio 4/5Give Primer VideoCurso dedicado al Proxy SIP Kamailio 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

September 10, 2024

• Andrea Sannucci Casos de Éxito: RTPEngine mask y transcoding – Parte 2

  En esta segunda parte veremos como configurar Kamailio para que utilice distintos RTPEngine para la parte media de las llamadas y que al mismo tiempo balancee la carga entre todos.

   

  Este tipo de configuración se puede realizar de dos formas:

   

  • utilizando un parámetro de la configuración del modulo de RTPEngine de Kamailio

  • utilizando la base de datos kamailio y más en especifico la tabla rtpengine

   

  En el primer caso el parámetro que nos interesa es:

   

  rtpengine_sock (string)

   

  y la configuración es bastante sencilla; se indican todos los servidores RTPEngine que se van a utilizar separados por un espacio y, si se quiere, asignando un peso a cada uno de ellos. Unos ejemplos:

   

  modparam("rtpengine", "rtpengine_sock", "udp:192.168.1.1:12221 udp:192.168.1.2:12222")

   

  en este caso se utilizarán dos RTPEngine que estarán a la escucha, uno sobre la IP 192.168.1.1, puerto 12221 y otro sobre la IP 192.168.1.2, puerto 12222. Ambos estarán a la escucha sobre el protocolo de trasporte UDP.

   

  Del lado de la configuración de RTPEngine el parámetro que nos interesa es:

   

  -n 192.168.1.1:12221

  -n 192.168.1.2:12222

   

  para el primero y el segundo servidor respectivamente. Otro ejemplo utilizando el peso sería:

   

  modparam("rtpengine", "rtpengine_sock", "udp:192.168.1.1:12221=2 udp:192.168.1.2:12222=1")

   

  el primero tendrá peso 2 y el segundo peso 1. Esto quiere decir que de 3 llamadas, dos serán gestionadas por el RTPEngine con peso 2 y una por el RTPEngine con peso 1.

   

  Otra configuración que se puede realizar es configurar los servidores RTPEngine en grupos y luego decidir en el script de enrutamiento que grupo utilizar para una determinada llamada, ejemplo:

   

  • grupo 1 para llamadas internas

  • grupo 2 para llamadas salientes

   

  La configuración sería algo parecido:

   

  modparam("rtpengine", "rtpengine_sock", "1 == udp:192.168.1.1:12221 udp:192.168.1.2:12222")

  modparam("rtpengine", "rtpengine_sock", "2 == udp:192.168.1.3:12221")

   

  Luego en el script de enrutamiento, antes de llamar la función rtpengine_manage, que se utiliza para activar RTPEngine, se pone la siguiente función:

   

  set_rtpengine_set(setid[, setid])

   

  donde se indica un grupo principal y uno secundario (si se necesita).

   

  Si utilizamos la base de datos, los campos de la tabla rtpengine son:

   

  

   

   

  • id: numero entero que se genera y se incrementa automáticamente para cada entrada

  • setid: grupo al que pertenecerá el servidor que se está configurando (predefinido 0)

  • url: protocolo de trasporte, ip y puerto donde estará a la escucha el servidor RTPEngine

  • weight: peso asignado al servidor (predefinido 1)

  • disabled: si el servidor está activo o no (predefinido 0 = activo)

  • stamp: una imprenta de tiempo donde se guardará la fecha y hora de configuración de la entrada

   

  y en la configuración del modulo habrá que utilizar el parámetro:

   

  db_url (string)

   

  donde se configurará la URL de conexión a la base de datos de Kamailio. Ejemplo:

   

  modparam("rtpengine", "db_url", "mysql://kamailio:password@localhost/kamailio")

   

  Una vez realizada la configuración y reiniciado Kamailio, tendremos disponibles unos comandos para realizar una serie de operaciones:

   

  kamcmd rtpengine.reload

   

  para recargar la configuración de la tabla rtpengine si se está utilizando la base de datos para la configuración de los servidores RTPEngine

   

  kamcmd rtpengine.enable

   

  para activar/desactivar un servidor RTPENgine

   

  kamcmd rtpengine.show all

   

  para ver la lista completa de servidores RTPEnngine configurados con los respectivos parámetros. Ejemplo:

   

  

   

  kamcmd rtpengine.ping

   

  para enviar un ping al servidor RTPEngine que si no contesta será considerado no activo. Ejemplo:

   

  kamcmd rtpengine.ping udp:127.0.0.1:2223

   

   

  

   

  Creo que es todo, les recuerdo que para gestionar los servidores RTPEngine es posible utilizar la utilidad rtpengine-ctl cuya configuración se ha mostrado en esta entrada

   

   

  • RTPEngine
  • rtpengine-ctl
  • Kamailio
  • Balanceo

  Vota el Articulo: 

  VotarGive Casos de Éxito: RTPEngine mask y transcoding – Parte 2 1/5Give Casos de Éxito: RTPEngine mask y transcoding – Parte 2 2/5Give Casos de Éxito: RTPEngine mask y transcoding – Parte 2 3/5Give Casos de Éxito: RTPEngine mask y transcoding – Parte 2 4/5Give Casos de Éxito: RTPEngine mask y transcoding – Parte 2 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

September 08, 2024

• Andrea Sannucci Casos de Éxito: RTPEngine mask y transcoding

  EL PROBLEMA

   

  El cliente necesitaba un servidor intermedio que funcionara de Gateway entre sus clientes y sus proveedores; los clientes utilizaban todos los codec audio menos G729 y con el proveedor todo tenía que salir con G729 para ahorrar banda y no superar los limites de la fibra disponible. Además de eso el servidor tenía que soportar unos 100 CPS (INVITEs por segundo) y alrededor de unas 1500 llamadas concurrentes.

   

  ANÁLISIS

   

  Realizando una primera análisis se descartó por completo Asterisk PBX y FreeSWITCH: Asterisk PBX porque tiene bastantes problemas con altos CPS y FreeSWITCH porque no garantizaba algunas manipulaciones de los codec audio presentes en el anexo SDP que se necesitaba realizar.

   

  LA SOLUCIÓN

   

  Se optó para instalar Kamailio en un servidor de 12 dólares de Linode y un Cluster de servidores con instalado solamente RTPengine gestionados desde el Kamailio. Para RTPEngine se ha optado para unos 20 servidores de Linode de 5 dólares considerando que, gracias a las pruebas realizadas, cada servidor lograba gestionar unas 80 llamadas con trascoding. 80 x 20 = 1600 llamadas concurrentes

   

  En la parte dedicada al enrutamiento de las solicitudes SIP a nivel de Kamailio, se ha configurado que para todos los INVITEs recibidos se activara RTPEngine aprovechando las siguientes opciones disponibles:

   

  • codec-strip

  • codec-mask

  • codec-trascode

  con codec-strip se han eliminado todos los codec audio que no fueran PCMA o PCMU, ejemplo:

   

  • codec-strip-G722, codec-strip-opus

  con codec-mask se han enmascarado los codec que no se querían negociar con el proveedor pero que si quedaban negociables con el cliente, ejemplo:

   

  • codec-mask-PCMU codec-mask-PCMA

  por ultimo se ha añadido la opción que permitía el trascoding entre PCMA y PCMU del lado cliente con el G729 del lado proveedor:

   

  • codec-trascode-G729

  Después de probar el sistema en laboratorio y tener la certeza que funcionaba correctamente, se ha pasado en producción donde tiene casi un año funcionando sin problemas. Costo mensual de alquiler de servidores: 112 dólares.

   

  En una próxima entrada les hablaré de como configurar en Kamailio un cluster de servidores RTPEngine.

   

  Me cuentan

   

  • Kamailio
  • RTPEngine
  • Transcoding

  Vota el Articulo: 

  VotarGive Casos de Éxito: RTPEngine mask y transcoding 1/5Give Casos de Éxito: RTPEngine mask y transcoding 2/5Give Casos de Éxito: RTPEngine mask y transcoding 3/5Give Casos de Éxito: RTPEngine mask y transcoding 4/5Give Casos de Éxito: RTPEngine mask y transcoding 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

September 06, 2024

• Andrea Sannucci El NIST Aprueba los primeros tres estándar de criptografía post cuántica

  El NIST (El instituto nacional de estándar y tecnología de Estados Unidos) el 13 de agosto 2024 ha aprobado los primeros tres estándar de criptografía post cuántica. De estos tres estándar, uno, ML-KEM, está basado en Kyber y utilizado para la negociación de claves; los otros dos, ML-DSA y SHL-DSA, utilizados para la firmas digitales.

   

  Ahora la pregunta: ¿Porque crear sistemas de criptografía cuánticos si todavía no existen computadores con esta potencia y están lejos de aparecer (unos diez/veinte años?)

   

  1. Es mejor tener sistemas de criptografía capaces de resistir a la potencia de calculo de los computadores cuánticos mucho antes de que estos computadores se creen, que no tenerlos

  2. poder empezar a utilizar estos estándar sabiendo que todos los datos que se van a proteger no van a ser crackeado en el futuro. De hecho algunas empresa han empezados a utilizar Kyber sobre TLS mucho antes que se anunciara su estandarización

  Algunas notas:

   

  • KYBER es un mecanismo de encapsulación de clave. Es utilizado para establecer una clave compartida entre dos partes que quieren empezar una comunicación

  • Una firma digital se representa como una cadena de bits y se calcula utilizando un conjunto de reglas y parámetros que permiten verificar la identidad del firmante y la integridad de los datos. Las firmas digitales pueden generarse tanto en datos almacenados como transmitidos

  • ML está por modulo látex y es un sistema de criptografía que involucra estructuras geométricas complejas conocidas como lácticos

  • SHL está por Stateless HASH-BASED e indica el uso de algoritmos de criptografía basados en la funciones HASH, funciones que permiten garantizar la seguridad y que permiten mapear datos de cualquier tamaño asociándolos a valores de tamaño fijo.

   

  ¿Qué opinan?

   

  • NIST
  • ML-KEM
  • ML-DSA
  • SLH-DSA
  • Criptografía
  • Computadores Cuánticos

  Vota el Articulo: 

  VotarGive El NIST Aprueba los primeros tres estándar de criptografía post cuántica 1/5Give El NIST Aprueba los primeros tres estándar de criptografía post cuántica 2/5Give El NIST Aprueba los primeros tres estándar de criptografía post cuántica 3/5Give El NIST Aprueba los primeros tres estándar de criptografía post cuántica 4/5Give El NIST Aprueba los primeros tres estándar de criptografía post cuántica 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

September 05, 2024

• Andrea Sannucci La primera LEY al mundo que reglamenta la IA es Europea

  Hace unos meses, marzo 2024, el Parlamento Europeo ha aprobado una Ley que reglamenta el uso y el alcance de la inteligencia artificial en todo el territorio de la Union.

   

  El la primera ley orgánica sobre la IA aprobada en el mundo y creo que todos los ciudadanos europeos deberían ser bastante orgullosos de eso aunque puede ser que no sea la mejor ley posible.

   

  La idea de esta ley, por lo que tengo entendido, es fomentar la IA en el respeto de la privacidad y de los derechos de los ciudadanos europeos. La palabra clave de la lay es inferencia es decir la capacidad de deducir algo a partir de los datos disponibles.

   

  A seguir algunas frases extractas del texto de la ley que encuentran en anexo en Español y Italiano:

   

  “debe ser una herramienta para las personas y tener por objetivo último aumentar el bienestar humano”

   

  “Una característica principal de los sistemas de IA es su capacidad de inferencia. Esta capacidad de inferencia se refiere al proceso de obtención de información de salida, como predicciones, contenidos, recomendaciones o decisiones, que puede influir en entornos físicos y virtuales, y a la capacidad de los sistemas de IA para deducir modelos o algoritmos a partir de información de entrada o datos”

   

  “Deben prohibirse los sistemas de categorización biométrica basados en datos biométricos de las personas físicas, como la cara o las impresiones dactilares de una persona física, para deducir o inferir las opiniones políticas, la afiliación sindical, las convicciones religiosas o filosóficas, la raza, la vida sexual o la orientación sexual de una persona física. Dicha prohibición no debe aplicarse al etiquetado, al filtrado ni a la categorización lícitos de conjuntos de datos biométricos adquiridos de conformidad con el Derecho nacional o de la Unión en función de datos biométricos, como la clasificación de imágenes en función del color del pelo o del color de ojos, que pueden utilizarse, por ejemplo, en el ámbito de la aplicación de la ley.”

   

  “El uso del sistema de identificación biométrica remota en tiempo real en espacios de acceso público solo debe autorizarse si la correspondiente autoridad encargada de la aplicación de la ley ha llevado a cabo una evaluación de impacto relativa a los derechos fundamentales y, salvo que se estipule otra cosa en el presente Reglamento, si ha registrado el sistema en la base de datos establecida en el presente Reglamento.”

   

  ¡Interesante!

   

  Adjunto	Tamaño
  a-9-2023-0188-am-808-808_es.pdf	940.87 KB
  a-9-2023-0188-am-808-808_it.pdf	921.8 KB

  • IA
  • Inteligencia Artificial
  • Europa
  • Ley

  Vota el Articulo: 

  VotarGive La primera LEY al mundo que reglamenta la IA es Europea 1/5Give La primera LEY al mundo que reglamenta la IA es Europea 2/5Give La primera LEY al mundo que reglamenta la IA es Europea 3/5Give La primera LEY al mundo que reglamenta la IA es Europea 4/5Give La primera LEY al mundo que reglamenta la IA es Europea 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

August 13, 2024

• Andrea Sannucci Adios Dashlane, bienvenido BitWarden

  Dashlane es un gestor de contraseñas que he utilizado por unos años. El otro día he recibido un correo electrónico a la dirección registrada en el programa donde la empresa detrás de Dashlane anunciaba un aumento de precios; inicialmente me pareció algo justo ya que los precios no los actualizaban desde hace rato. El problema es que antes pagaba 19.900 pesos colombianos/año y con la nueva tarifa iba a pagar 299.900 pesos colombianos/año, un aumento del 1400% o, si prefieren, 15 veces más de lo que pagaba anteriormente…

   

  Afortunadamente, después de una rápida búsqueda he encontrado una alternativa valida, segura y fácil de implementar: BitWarden, un programa de gestor de contraseñas Open Source con las fuentes publicadas en Github.

   

  Quedaba el problema de como pasar los datos de DashLane a Bitwarden y aquí también, después de una búsqueda puntual, he encontrado la solución.

   

  Para exportar los datos de Dashlane a una hoja de calculo en formato CSV.

   

  Para importar los datos en BitWarden desde una hoja de calculo en formato CSV de Dashlane:

   

  

  Problema resuelto…

   

  ¿Han vivido una situación parecida

   

  • Password Manager
  • Bitwarden
  • Dashlane

  Vota el Articulo: 

  VotarGive Adios Dashlane, bienvenido BitWarden 1/5Give Adios Dashlane, bienvenido BitWarden 2/5Give Adios Dashlane, bienvenido BitWarden 3/5Give Adios Dashlane, bienvenido BitWarden 4/5Give Adios Dashlane, bienvenido BitWarden 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  • 

July 08, 2024

• Andrea Sannucci OpenSIPs eBootCamp 2024 – Certificación oficial en OpenSIPs

  Justo hoy, en la lista de distribución de los usuarios de OpenSIPs, he recibido un mensaje donde se anuncia el próximo curso en linea dedicado al Proxy SIP OpenSIPs y dictado por los mismos desarrolladores.

   

  Algunos datos:

   

  • Duración: 40 horas (4 horas diarias)

  • Hora: de 15:00 a 19:00 GMT

  • Fechas: del 14 al 25 de octubre 2024

  • Costo: 1890 dólares antes del 31 de Julio, 2100 dólares desde el 31 de Julio

  • Certificación si se supera un examen final

   

  Objetivos del curso (en inglés):

   

  • Learn OpenSIPS from the experts

  • Develop communication applications based on one of the most popular SIP servers in the market

  • Provide technical support as a master, reducing the time to solve problems

  • Reduce the time to implement a project

  • Enhance your consulting career by becoming an OpenSIPS Certified Professional

   

  Requisitos mínimos para participar:

   

  • Basic Linux knowledge

  • Basic text editing

  • Basic SIP protocol (Free online learning - OpenSIPS Quickstart elearning.opensips.org)

  • Basic OpenSIPS Knowledge (Free online learning - OpenSIPS Quickstart elearning.opensips.org)

  • Programming logic knowledge (you won't need to program, but you need to understand logical concepts applied to the dial-plan)

  Curso basado en la versión 3.5 de OpenSIPs

  ¿Qué opinan?

   

  • OpenSIPs
  • eBootCamp

  Vota el Articulo: 

  VotarGive OpenSIPs eBootCamp 2024 – Certificación oficial en OpenSIPs 1/5Give OpenSIPs eBootCamp 2024 – Certificación oficial en OpenSIPs 2/5Give OpenSIPs eBootCamp 2024 – Certificación oficial en OpenSIPs 3/5Give OpenSIPs eBootCamp 2024 – Certificación oficial en OpenSIPs 4/5Give OpenSIPs eBootCamp 2024 – Certificación oficial en OpenSIPs 5/5

  Sin votos (todavía)

  Evalúa la calidad del articulo

  • 
  • 
  •