La versión 2.7.2 separa las llamadas entrantes y salientes en dos cadenas de eventos de webhook independientes, añade control de colas a través de la API REST e identificación de troncales SIP por cabecera para gateways donde varias líneas comparten una misma IP.
Una cadena de eventos independiente para llamadas salientes
Antes, las llamadas salientes realizadas desde la extensión de un usuario SIP no tenían eventos
propios en absoluto. Ahora existe call.outgoing → call.outgoing_answered →
call.outgoing_ended, independiente de la cadena entrante call.incoming → call.answered /
call.missed → call.ended. El reconocimiento de una llamada saliente está ligado al usuario
SIP concreto, no al contexto del dialplan — esto importa porque tanto un usuario como una
troncal pueden compartir un nombre de contexto que coincide con el nombre de una tabla de
enrutamiento.
linkedid, channel y channel_vars en cada evento
Cada payload ahora incluye linkedid — un identificador compartido por todos los canales de una
misma llamada lógica (por ejemplo, ambas piernas de una llamada interna) — y channel, el
nombre del canal de Asterisk. Esto permite que un CRM agrupe varios eventos de webhook de la
misma llamada sin depender de la cercanía de uniqueid ni de marcas de tiempo. Un nuevo objeto
channel_vars transporta los valores de las variables de canal de Asterisk permitidas (por
defecto, ULINE, el slot de aparcamiento de llamadas).
Pausa y estado de los agentes de cola vía la API REST
POST /api/v1/queues/members/pause/ pausa o reactiva a un agente de cola mediante el
QueuePause de AMI, y GET /api/v1/queues/members/ devuelve el estado en vivo de los agentes
(pausa, estado, llamadas atendidas) — ambos endpoints trabajan directamente contra Asterisk, sin
importar si dashboard-listener está en ejecución.
Troncales SIP para gateways GSM multipuerto
Un nuevo campo de texto libre, custom_identify_settings, permite definir un bloque
[identify] personalizado para una troncal. Esto resuelve un problema concreto: cuando varios
puertos del mismo gateway GSM se registran desde una única IP, Asterisk no puede distinguirlos
por IP — solo por la cabecera Contact: de la petición entrante. Antes, [identify] solo
admitía el reconocimiento por IP.
Un cambio importante para los webhooks existentes que usan tablas de enrutamiento
Si tienes un webhook configurado para coincidir solo por tabla de enrutamiento (sin contexto
ni cola) en eventos entrantes, después de actualizar esas llamadas empezarán a enviarse como
call.outgoing* en lugar de call.incoming/call.ended, como antes. La migración traslada
automáticamente la configuración existente, pero hay que actualizar el manejador del lado del
CRM para que espere los nuevos tipos de evento. Orden de actualización recomendado: primero
migrate y sync_webhooks, luego reiniciar dashboard-listener.