Análisis de Telefonía

Por qué Asterisk es el único sustrato viable

Stack SIP/RTP: 20+ años de desarrollo

Asterisk es el resultado de más de dos décadas de desarrollo continuo en el stack de telecomunicaciones. Su base de media está construida sobre pjproject, la implementación SIP/RTP más madura y probada en el mundo open source.

Las capas que Asterisk resuelve automáticamente:

SIP signaling: registro, invitación, re-INVITE, BYE, suscripciones SUBSCRIBE/NOTIFY. Manejo de codecs, SDP negotiation, session timers.
RTP media: streaming de audio/video, jitter buffer adaptativo, DTMF (RFC 2833, SIP INFO, in-band), comfort noise (RFC 3389).
Transcodificación de codecs: G.711 (alaw/ulaw), G.722, Opus, Speex, GSM, iLBC, y muchos más. La transcodificación es computacionalmente costosa y depende de la plataforma. Asterisk la optimiza a nivel de procesador.
NAT traversal: ICE, STUN, TURN para comunicación detrás de firewalls y NAT. Implementación correcta de NAT traversal es uno de los problemas más difíciles en VoIP. Asterisk lo resuelve con rtp ICE stack.
DTLS-SRTP: encriptación de media end-to-end. Seguridad crítica para cumplimiento de regulaciones de privacidad.

Nunca reimplementar estas capacidades. La complejidad es abrumadora y el costo de errores de seguridad o rendimiento es inaceptable. Asterisk las resuelve de forma probada por miles de implementaciones en producción.

Ventajas competitivas de Asterisk

Comunidad activa: décadas de contribuciones, parches de seguridad, y soporte.
Documentación extensa: wikis, libros, foros, y ejemplos de producción.
Interoperabilidad probada: funciona con cualquier phone, gateway, o troncal SIP del mercado.
Rendimiento probado: maneja miles de canales concurrentes en hardware estándar.
Licencia GPLv2 con protocol exception: la exception permite que aplicaciones externas se comuniquen con Asterisk vía AMI/ARI sin infectarse con la licencia GPL.

ARI (Asterisk REST Interface) - El punto de integración correcto

Arquitectura de ARI

ARI es la interfaz moderna de Asterisk para controlar llamadas y recursos de media desde aplicaciones externas. Es el punto de integración correcto para una plataforma de contact center.

sequenceDiagram
    participant App as Nuestra Aplicación
    participant ARI as Asterisk ARI
    participant Dialplan as Dialplan
    participant Media as Media Engine

    Note over ARI: WebSocket para eventos
    App->>ARI: Subscribe to StasisStart
    ARI-->>App: Event: ChannelCreated
    
    App->>ARI: POST /channels (Originate)
    ARI->>Dialplan: Execute dialplan
    Dialplan->>Media: Bridge channels
    Media-->>ARI: Media flowing
    ARI-->>App: Event: ChannelAnswered
    
    App->>ARI: POST /bridges (Create Bridge)
    ARI-->>App: Bridge created
    App->>ARI: POST /channels/{id}/play
    ARI->>Media: Play audio

Capas de ARI

REST API (síncrona):

HTTP/HTTPS endpoints para operaciones de control.
JSON como formato de datos.
HTTP Basic authentication (o token-based con proxy inverso).
Ideal para: originate, answer, hangup, transfer, play, record.

WebSocket (eventos):

Conexión WebSocket persistente para recibir eventos en tiempo real.
Eventos del ciclo de vida de canales, bridges, y media.
Ideal para: monitoreo en tiempo real, reacción a eventos,的状态 actualizations.

Protocol exception en GPLv2

La protocol exception de Asterisk es fundamental para nuestro modelo de negocio:

Asterisk está licenciado bajo GPLv2.
Las aplicaciones que se comunican con Asterisk exclusivamente a través de AMI o ARI no se consideran derivadas de Asterisk.
Esto significa que nuestras aplicaciones propietarias pueden usar ARI sin obligación de abrir código fuente.
Restricción: no podemos modificar el código fuente de Asterisk y distribuirlo sin cumplir GPLv2. Si necesitamos personalizar Asterisk, debemos hacerlo como parches aplicados en deploy, no como redistribución.

Lo que ARI puede controlar

Canales (llamadas):

Originate: iniciar una llamada a un destino específico.
Answer: contestar una llamada entrante.
Hangup: finalizar una llamada.
Transfer: transferir una llamada a otro destino (attended o blind).
Redirect: redirigir a un destino del dialplan.
SetVariable / GetVariable: manipular variables de canal.
Snoop: espiar o susurrar en una llamada (spy/whisper).
SendDTMF: enviar tonos DTMF.

Bridges (conferencias y conferencias):

Create Bridge: crear un bridge (tipo mix, que es una conferencia).
AddChannel: agregar un canal a un bridge (unir dos o más llamadas).
RemoveChannel: quitar un canal de un bridge.
Play: reproducir audio a través del bridge.
Record: grabar todo el audio del bridge (conferencia).

Media:

Play: reproducir audio, video o DTMF a un canal.
StartRecording: iniciar grabación de un canal individual.
StopRecording: detener grabación.
GetMedia (via external media): enviar/recibir media por UDP para integración con procesamiento externo.

Aplicaciones Stasis:

Cada aplicación ARI se registra como una aplicación Stasis.
El dialplan redirige canales a la aplicación Stasis.
La aplicación controla completamente el comportamiento del canal.
Múltiples aplicaciones Stasis pueden coexistir (una por tenant, o una global con routing).

AMI (Legacy - Solo monitoreo)

Características

Protocolo de texto TCP: protocolo basado en texto sobre TCP, similar al estilo de Asterisk CLI.
Eventos y comandos: recibe eventos y envía comandos de texto.
Maduro y estable: décadas de uso en producción.

Cuándo usar AMI

Monitoreo:接收 eventos en tiempo real para dashboards y métricas.
Operaciones de cola: QueueAdd, QueueRemove, QueuePause para gestión de agentes en colas.
Reporting: conteo de llamadas activas, duración, estado.
No para nuevo desarrollo: ARI es superior para nuevas funcionalidades.

Limitaciones de AMI vs ARI

Aspecto	AMI	ARI
Protocolo	Texto TCP	REST + WebSocket
Complejidad	Mayor (parsing de texto)	Menor (JSON)
Control de media	Limitado	Completo
Eventos en tiempo real	✅	✅ (WebSocket)
Documentación	Extensa pero antigua	Moderna y clara
Recomendado para	Monitoreo, operaciones legacy	Nuevo desarrollo

Queuing / ACD

Colas de Asterisk

Asterisk incluye un sistema de colas (queues) con estrategias predefinidas para distribución de llamadas:

8 estrategias de distribución:

ringall: suena a todos los agentes disponibles simultáneamente.
leastrecent: prioriza al agente que lleva más tiempo sin recibir llamada.
fewestcalls: prioriza al agente con menos llamadas atendidas.
random: distribución aleatoria entre agentes disponibles.
rrmemory: round-robin con memoria (recuerda el último agente que atendió).
rrordered: round-robin ordenado (lista de agentes en orden fijo).
linear: distribución lineal siempre en el mismo orden.
wrandom: weighted random (pesos por agente).

Sistema de penalización

Cada agente puede tener una penalización (penalty) de 1 a 10.
Agentes con menor penalización son contactados primero.
Permite crear grupos de agentes prioritarios y de respaldo.
Ejemplo: agentes senior (penalty 1) reciben llamadas primero, agentes junior (penalty 2) solo cuando los senior no están disponibles.

Lógica de cola personalizada via ARI

Para casos donde las estrategias nativas no son suficientes:

Implementar lógica de routing personalizada en nuestra aplicación.
Usar ARI para recibir eventos de llamadas entrantes.
Aplicar algoritmos de routing basados en skills, disponibilidad, o datos del CRM.
Dirigir la llamada al agente correcto vía ARI (originate o redirect).

Híbrido: usar colas de Asterisk para manejo básico de media (ring, hold, music-on-hold) y nuestra lógica para routing inteligente.

IVR (Interactive Voice Response)

Dialplan-based vs ARI-controlled

Dialplan-based IVR:

Configuración estática en el dialplan de Asterisk.
Uso de applications como Read (para DTMF), Background (para menú de voz).
Limitado pero simple.
Adecuado para IVR estáticos que no cambian frecuentemente.

ARI-controlled IVR:

Nuestra aplicación controla completamente el flujo IVR.
Escucha eventos StasisStart, reproduce audio vía Play, espera DTMF vía eventos.
Totalmente dinámico y configurable.
Permite IVR basados en datos del CRM, personalización, y lógica compleja.

Capacidades

Recolección de DTMF: captura de números de identificación, selecciones de menú.
Speech recognition: integración con motores de reconocimiento de voz (local o cloud).
Text-to-Speech: generación de voz dinámica.
Enrutamiento: transferencia a agente, queue, o buzón de voz.
External IVR via AGI/Stasis: completamente controlado desde código externo.

Recomendación

IVR dinámico via ARI. El IVR es parte de la lógica de negocio y debe ser configurable por tenant, medible, y adaptable sin reiniciar Asterisk.

Grabación

Tipos de grabación

MixMonitor:

Grabación de canal individual (una lado de la conversación).
Configuración vía dialplan o ARI.
Formato: WAV, MP3, o configuarble.
Uso: grabación de agentes individual, quality assurance.

Bridge Recording:

Grabación de un bridge (conferencia o conversación completa).
Captura ambos lados de la conversación.
Ideal para grabación de llamadas de contact center.

ARI Channel Recording:

Grabación programática vía ARI.
Control completo de inicio/fin de grabación.
Metadatos personalizables (tenant ID, agent ID, etc.).

Pipeline post-proceso

Después de la grabación:

Almacenamiento: subir a almacenamiento persistente (S3, filesystem distribuido).
Indexación: registrar en base de datos con metadatos (caller, agent, duration, tenant).
Transcripción: pipeline de speech-to-text para búsquedas y análisis.
Retention: política de retención y eliminación automática.
Acceso: streaming bajo demanda para supervisores.

WebRTC

Capacidades de Asterisk

Asterisk soporta WebRTC nativamente para agentes basados en navegador:

Transporte:

SIP over WSS (WebSocket Secure).
Necesario para comunicación desde navegador (no soporta UDP directamente).

NAT Traversal:

ICE (Interactive Connectivity Establishment).
STUN (Session Traversal Utilities for NAT).
TURN (Traversal Using Relays around NAT) como fallback.
Asterisk actúa como servidor ICE endpoint.

Seguridad:

DTLS-SRTP para encriptación de media end-to-end.
Certificados TLS para señalización.

Codecs:

Opus: preferido para calidad en navegador, bajo ancho de banda, y tolerancia a packet loss.
G.711: fallback para compatibilidad con PSTN.

Agentes basados en navegador

Con WebRTC, los agentes no necesitan softphone:

Widget de teléfono en el navegador.
Auriculares USB o audífono del dispositivo.
Sin instalación de software adicional.
Ideal para agentes remotos y work-from-home.

Configuración necesaria

Servidor STUN/TURN (Coturn es una opción open source).
Certificados TLS válidos.
Configuración de WebRTC en pjsip.conf o sip.conf.

Multi-tenancy con Asterisk

Contexts para separación de dialplan

Cada tenant tiene su propio context en el dialplan:

[tenant_acme]
include => tenant_acme_internal
include => tenant_acme_external
include => tenant_acme_outbound

[tenant_globex]
include => tenant_globex_internal
include => tenant_globex_external
include => tenant_globex_outbound

Los contextos aíslan:

Extensiones internas (solo agentes del tenant).
Números externos (DIDs del tenant).
Reglas de enrutamiento saliente.

ARI applications por tenant

Opción 1: Una aplicación ARI por tenant.

Cada tenant tiene su propio Stasis application.
Routing de canales a la aplicación correcta basándose en el DID o contexto.
Más aislamiento, más recursos (una conexión WebSocket por tenant).

Opción 2: Una aplicación global con routing.

Una sola aplicación ARI maneja todos los tenants.
Routing interno basado en variables de canal.
Más eficiente en recursos, pero más complejo.

Recomendación: Opción 1 para开始. El aislamiento es más importante que la eficiencia de recursos en las primeras fases.

Configuración vía base de datos (Sorcery)

Asterisk permite configuración dinámica desde base de datos:

[general]
 SorceryConfig => sorcery.conf

[sorcery]
 realtime => realtime

Esto permite:

Crear extensiones sin reiniciar Asterisk.
Modificar configuración de troncales en tiempo real.
Gestión de colas y miembros dinámicamente.
Configuración por tenant en la base de datos.

Monitoreo de recursos por tenant

Canales activos: conteo de canales concurrentes por tenant.
Llamadas por día: tracking de volumen de llamadas.
Duración promedio: métricas de calidad de servicio.
Uso de códecs: monitoreo de transcodificación (impacto en CPU).
Alertas: notificación cuando un tenant se acerca a límites de capacidad.

Consideraciones de despliegue

Limitación de proceso único

Asterisk es un proceso single-process (multi-threaded). Esto significa:

No escala horizontalmente de la misma instancia.
Un bloqueo en Asterisk afecta a todos los tenants.
La memoria y CPU son compartidas.

Escalamiento horizontal vía Kamailio

Kamailio actúa como proxy SIP front-end:

graph LR
    Clients[Clientes/WebRTC] --> Kamailio
    Kamailio --> Asterisk1[Asterisk 1]
    Kamailio --> Asterisk2[Asterisk 2]
    Kamailio --> AsteriskN[Asterisk N]

Funciones de Kamailio:

Load balancing: distribuye llamadas entre múltiples instancias de Asterisk.
Failover: redirige tráfico si una instancia falla.
Registration: maneja registros SIP de agentes WebRTC.
Topology hiding: oculta la topología interna.
Routing: enrutamiento basado en reglas, DNIS, ANI.

Separación de telefónica y lógica de negocio

Principio fundamental:

Asterisk maneja SOLO: media, señalización, grabación, WebRTC, transcodificación.
Nuestra aplicación maneja: routing inteligente, CRM, conversaciones, campañas, reporting.
Comunicación: ARI para control, AMI para monitoreo.

Esto permite:

Actualizar la lógica de negocio sin reiniciar Asterisk.
Escalar la lógica de negocio independientemente de la telefónica.
Mantener la estabilidad de Asterisk (no sobrecargarlo con lógica de aplicación).