Los parámetros relacionados con la configuración del qualify en PJSIP se utilizan en un bloque de tipo AOR y son tres:

• qualify_frequency: cada cuantos segundos enviar un paquete de tipo OPTIONS a los dispositivos registrados para conocer su estado y mantener abierta la conexión si hay NAT por el medio
• qualify_timeout: si el dispositivo no contesta al paquete OPTIONS enviado dentro de los segundos indicados en este parámetro, se considerará no disponible. El valor se puede indicar con decimales; Ejemplo 3.5 (tres segundos y medio)
• authenticate_qualify: si el OPTIONS enviado recibe como respuesta una solicitud de autenticación, el dispositivo se considerará disponible solamente al terminar el proceso de autenticación

El sistema se basa en el envío de una paquete SIP de tipo OPTIONS que nos permite conocer si el dispositivo está todavía disponible o no y el tiempo en que tarda en llegar la respuesta a nuestra PBX. Antes de las versiones 13.22.0 y 15.5.0 de Asterisk su implementación tenía algunas falencias en términos de prestaciones y de funcionamiento con los usuarios configurados en Realtime (base de datos).

Mientras antes en un sistema con 3000 dispositivos a que "calificar" el arranque de Asterisk se tardaba hasta 3 minutos y se presentaba un consumo considerable de CPU, con el nuevo sistema, de tres minutos se ha pasado a algunos segundos y el consumo de CPU máximo es del 15%.

¿Cómo funciona el nuevo sistema?

Il resultado del envío del paquete OPTIONS al dispositivo es suministrado al AOR. El AOR añade la información con los otros contactos presentes (a un AOR, en PJSIP, pueden estar asociados uno o más contactos). Si el estado del AOR no ha cambiado, no pasa nada; si el estado del AOR ha cambiado, la información es facilitada a todos los Endpoints que utilizan ese bloque de tipo AOR. Los Enpoints añaden la información con los demás AOR. Si el estado del Endpoint no ha cambiado, no pasa nada; si el estado ha cambiado, este nuevo estado es propagado al resto del sistema.

Lo bueno de todo esto es que el usuario final no debe hacer absolutamente nada. Solamente si se cambia la configuración de un bloque AOR en la base de datos, hay que recargar la configuración desde la consola de Asterisk o con el comando systemctl reload asterisk.

Parece que esta nueva implementación, ha tenido, como efecto secundario, la solución de un BUG que afectaba el funcionamiento del Multi dominio en PJSIP. He realizado algunas pruebas y parece que ahora se pueden configurar distintos Endpoint con los mismos números/nombres modificando el dominio/subdominio asociado. Ejemplo:

[1000@sip10.voztovoice.org]
type= endpoint
context=clienteA

[1000@sip11.voztovoice.org]
type=endpoint
context=ClienteB

Además esta nueva configuración aumenta el nivel de seguridad ya que no se aceptarán registros sobre la IP del servidor sino solamente si se utiliza el respectivo dominio.

A nivel de dialplan:

[ClienteA]
exten => _100[0-3],1,Dial(PJSIP/${EXTEN}@sip10.voztovoice.org,30)
same => n,Hangup

[CLienteB]
exten => _100[0-3],1,Dial(PJSIP/${EXTEN}@sip11.voztovoice.org,30)
same => n,Hangup

Hagan pruebas y me cuentan...