Escalabilidad “horizontal” en soluciones VoIP basadas en Asterisk / Kamailio

Escalabilidad “horizontal” en soluciones VoIP basadas en
Asterisk / Kamailio.
Carlos Cruz
Gorka Gorrotxategi

Charla VOIP2DAY 2016
• Objetivos de la presentación
– Puesta en común de los desafíos y soluciones
para el escalado horizontal en soluciones
VozIP basadas en Kamailio / Asterisk.
● Especial atención a las nuevas
posiblidades con PJSIP.
● Siempre hablando desde la perspectiva IP
PBX !
– Dangerous Demos ;)
● Un poco de emoción para empezar este
segundo día del fantástico voip2day 2016!

Antes de comenzar ...
• La idea principal es que no sea una
charla comercial ;) Esperamos no
aburriros ;)
• Quizás nos recordéis del VOIP2DAY
2009 ;) La primera charla del Irontec
Engineering Team ;)
– Primicia mundial! MCTL.
– Con la aprobación incluso de IBC!
● No se atrevió a desafiarnos
con una mejor
implementación, como cuenta
la leyenda que no puede
evitarlo ;)
– Production ready XD!

Para esta ocasión ….
• IVOZ Provider!
– Exposición previa de nuestro compi Gorka Rodrigo
en el workshop ;)
– En esta charla no nos centraremos en ello, no
pretende ser una exposición de producto, sino una
puesta en común de lo que hemos aprendido.
– Keypoints generales
● Open Source, liberado “ayer”.
● Diseñado con la mente en:
– Crecer horizontalmente.
– Integrable en entornos de operador.
● API’s, Provisión y conceptos clave OSS/BSS
– Multi-(marca|empresa|usuario)

IVOZ Provider
• Perspectiva de niveles

• Arquitectura General
IVOZ Provider

IVOZ Provider: Soft Tech’s usadas
RTPENGINE

Entrando en harina: Elasticidad / Crecimiento horizontal• IVOZ Provider!
– Exposición previa de nuestro compi Gorka Rodrigo en el
workshop ;)
– Keypoints generales
● Open Source, GPL
● Diseñado con la mente en:
– Integrable en entornos de operador.
– Multi-(marca|empresa|usuario)
elástic@: Del lat. mod. elasticus, y este del gr. elastósἐλαστός
'maleable' y el lat. - cus ' ico'.ĭ ‒‒

Crecimiento con Asterisk y Kamailio
• Escalabilidad
– Antes de nada, lo habitual: ¿De verdad queremos escalar de una forma
diferente a añadir más hierro?
● Mas de un nodo: HA! Discovering, dolores de cabeza con Split Brains, Fencing si o si (STONITH
or DIE!).
● No suele ser mucho “añadir y fin”, como si fuera una chimenea “más madera” ?
– Una vez decidido que queremos si o si escalar:
● Generalmente, se habla de poner un Kamailio por delante y balancear
– Kamailio gestionando Register/Nat/Auth
● Asterisk como IP PBX
● EOF.

Entrando en harina: Elasticidad / Crecimiento horizontal• Escalabilidad horizontal
– Generalmente, se habla de poner un Kamailio por delante y
balancear
– Kamailio gestionando Register/Nat/Auth
● Asterisk como IP PBX
● EOF.

Proceso habitual de escalado
• Kamailio liberando a Asterisk
– Dispatcher module
● Check AS are alive
● Call load distribution!
– Registrar + usrloc + nathelper
● nat_bflag + sipping_bflag for NAT handling
– Path module
● Outboundproxy for REGISTERs
– Rtpengine / rtpproxy
● Keep audio away from Asterisk!

Espera un instante...
No tan rápido!
Esto significa ...

¿Simplemente más
Soft-Hard Asterisk
boxes
y c'est fini ?

¿Podemos grabar esto en piedra?
¿Cualquier llamada, a cualquier Asterisk?
¿Verdad verdadera?

Kamailio delante de Asterisk en el mundo IP PBX
• Problemáticas esperadas
– Call pickup.
– Presencia (blf ;) )
● Sí,
DEVICE_STAT
US
– ConfBridge
– Refers!
● Sí, transferencias, de todos los
colores ;)
– Queues!
¿Dividimos por
Empresas?
¿Volvemos a
Activo-Pasivo y
fin de la charla? ¿Quitamos
Features,
BOFH mode
ON?
¿De verdad
habíamos dicho
eso?
¿Seguro
que la piedra
No se borra?

Any Call to Any Asterisk
• Primer Desafío: Call Pickup
– Llamada a una extensión especial: e.g. *95
– Aplicación pickup en Asterisk:
● pickup(endpoint) Captura directa→
● pickup() Captura indirecta→
– 1 endpoint n pickupGroups↔
¿Qué pasa si la llamada a *95 se gestiona en un AS distinto al
que está procesando la llamada a capturar?

• Primer Desafío: Call Pickup
ds_next_dst() on failure_route (sequential vs parallel)

• Segundo desafío: Distributed Device State
– En versiones previas de Asterisk, posibilidades:
● CoroSync + OpenAIS
● XMPP PubSub
– Con PJSIP / Asterisk > 13 la cosa cambia:
● pjsip.conf:
– Para enviar estado:
● Objetos asterisk-publication
● Objetos outbound-publish
– Para recibir estado:
● Objetos inbound-publication
Fuente: https://wiki.asterisk.org/wiki/display/AST/Exchanging+Device+and+Mailbox+State+Using+PJSIP

● Publicar cambios de DEVICE-STATE:
Asterisk enviaría PUBLISH con sus cambios de device-state a 172.16.10.2
● Recibir cambios de DEVICE-STATE:
Los PUBLISH que reciba Asterisk de instance2 con información de estado,
actualizarán los device-state propios.

– Este ejemplo vale para 2 instancias de Asterisk.
– Que un Asterisk avise al resto no escala:
● El número de Asterisk no es fijo.
● Un Asterisk no sabe si está solo o si hay 100 Asterisk más.
● El tráfico de PUBLISH cargaría Asterisk (¡que tiene que gestionar la
llamada!)
– Solución empleada:
● Cada Asterisk envía a Kamailio los PUBLISH con sus cambios.
● Kamailio reenvía el PUBLISH al resto de AS-es:
– Dispatcher modules rocks!

– Kamailio redistribuye (utilizando dispatcher):
– Asterisk actualiza device-state:

– Flujo tras reiniciar un AS (o añadir uno nuevo):
– En caso de crash, los device-states vuelve a NOT_INUSE.

• Conclusiones del Segundo desafío:
– No se requiere SW adicional (PJSIP powered!)
– Todos los Asterisk tienen los mismos DEVICE STATE
– Los DEVICE STATE son clave para:
● Hints (BLF)
● Saber si un usuario está ocupado o no
● Colas
– NOTIFY/SUBSCRIBE: cada AS gestiona los que le
lleguen (al igual que los INVITEs, los SUBSCRIBE
también se reparten).

• Tercer desafío: ConfBridge
– Long time ago … Aplicación Asterisk que sustituye a MeetMe
– Múltiples Asterisk: posibles problemas de sincronía
1) El primer participante tiene que generar la conferencia en el AS que le
toque
2) El siguiente participante tiene que entrar en la conferencia creada, ¡no
crear una propia!
3) ¿Y si entran muy muy a la par?

– Solución 1: Salas de conferencias anidadas
● Crear la conferencia allá donde caiga la llamada
● Anidar los Asterisk por medio de chanlocals (vía Kamailio)
Es técnicamente viable pero…
– ¿Y si quiero echar a alguien de
la conferencia?
– Visualización web realtime
– ¿Voluntarios para mantener esto?
¡¡Tiene que haber una solución más simple!!

– Solución 2: ¡PJSIP AL RESCATE!
● PJSIP crea automáticamente un
DEVICE STATE por sala de conferencia
● Pero siempre tras meter el PIN.
● La introducción de PIN puede
provocar colisiones.
● Patch para poner en RINGING durante
la petición de PIN
– Liberado en github ;)

• Cuarto desafío: Refers
– REFER es el método SIP clave para las transferencias de llamada.
– 2 tipos de transferencia de llamadas:
Transferencia ciega: in-dialog REFER instando al B2BUA a crear otra llamada y conectar la actual.

– Transferencia atendida:

– Dibujemos ...
(vía AS01)
(vía AS02)
#define anycall2anyasterisk
Alice llama a Bob
+Alice llama a Bofh
+Alice les quiere poner en contacto
--------------------------------------------
= 481 Call/Transaction Does Not Exist
¿Todas las llamadas del
mismo usuario,
Mismo AS?
Quita ese
#define!

– Solución 1: las llamadas de un usuario a un AS
● Te pones triste porque pierdes escalado pero.. ¿qué le vas a hacer?
● Al menos sigue habiendo un cierto reparto
● Pero…
– A llama a B (AS001)
– A llama a C para transferir (AS001 forzado)
– C tenía otra llamada en curso con D (AS002)
– C inicia otra llamada:
● ¿Uso AS001 por si transfiere a B?
● ¿Uso AS002 por si transfiere a D?

– Solución 2: las llamadas de una empresa a un AS
● ¿Asignación estática empresa AS ?↔
– ¿No era esto lo que queríamos evitar? XD
● ¡Asignación dinámica!
– Primera llamada: AS que más libre esté
– Mientras haya en curso: ese mismo AS
– Una vez que cuelgan todos: AS más libre
● Al menos sigue habiendo un cierto reparto :(
● Pero…
– ¿Y si llaman justo a la par?
● Además: ¿podremos mirarnos al espejo? y decirnos:
– Oh yeah, hay crecimiento horizontal.
– Y venir aquí a contar la batallita del escalado.
● Quitamos la feature XFER y fin ?

– Solución 3: ¡¡PJSIP REPLACER LOGIC!!
● Cuando Asterisk 13 PJSIP recibe REFER con:
● Y no reconoce el Call-ID de Replaces, permite ejecutar dialplan en un contexto especial:
● Hacemos que este bloque llame al Kamailio que, al saber dónde se gestiona la llamada, lo
manda al AS oportuno.

– Charlie llama a 101 (dlg1 as003):→
– Charlie llama a 102 para transferir (dlg2 as002):→
– Sobre dlg1 llega el siguiente REFER:
– as003 no conoce este CallID...

– Diálogo adicional entre AS:

• Queues!
– Las colas plantean retos similares.
– En lo que respecta IVOZ Provider:
Todavía no hemos tomado una decisión.
– Posibles enfoques:
● Una cola Un AS (dislike)↔
– ¿shared last call? ¿Weight?
● Todas las colas Un AS (peor)↔
● Todas las colas en todos los AS-es, Any Call to Any Asterisk !!!
– En su momentos nos enfocamos (¿mala idea?)
● Votaciones con Corosync2
● Concepto de “other Asterisk” en queue_ent
● ¿Distributed Stasis Core?
– Se ha comentado que Matt Jordan ya está en ello!

Escalado más allá de Asterisk
• Asterisk escala horizontalmente...
– Ya podemos escalar nuestra instalación para trabajar con
múltiples Asterisk.
– Pero… una vez que la llamada está establecida, Asterisk no es
un problema para soportar altos niveles de concurrencia de
llamadas.
● Sí para soportar altos niveles de call-per-seconds ;)
– ¿Quién es el nuevo cuello de botella? Los media-relay que se
encargan de gestionar el audio.
Conclusión: hay que escalar los media-relay también!

Escalado más allá de Asterisk
• RTPProxy escala horizontalmente...
– Se puede crear tantos perfiles media-relay como sean necesarios.
– La ubicación de estos elementos tendrá que ser lo más próxima
posible a los usuarios finales:
● Hasta que llegue ICE, ¡hay que minimizar el media-path!
– Actualmente:
● Los media-relays se agrupan en sets.
● La asociación set empresa es manual.↔
– Evolución:
● Asignar ubicación a los sets.
● Asignar los sets en función de la ubicación del llamante (geoIP
Kamailio module).

… to be continued
• No nos da tiempo a hablar de todo … No hay que olvidarse
de:
– Topic Information Sharing (AMQP?)
– Containers!
● LXC, ¿Docker?, …
● Network Overlaying?
– Orchestration
● ¿Orchestra Director?
● ¿Launch AS on peak times?
– Asterisk High CPS / Dynamic Flow Strategys
● [A?]GI’s vs Pseudo static Dialplan?

Probando IVOZ Provider !• AnyCall2AnyAsterisk: Queues
– xx
DEMO TIME!

Esto que vamos a enseñar
• IVOZ Provider is free! Lo podéis probar vosotr@s mism@s
– Entry point:
● https://github.com/irontec/ivozprovider
– Debian packages disponibles
– ISO disponible
● Single machine quick test.
– Documentación
– SOS / Contribute
● Users Mailing List
● Dev Mailing List

Basta de charla !
Ahh
¿Pero había
que enseñarlo?
Bob!
Prepara el
cartonpiedra!
Bob!
Prepara el
cartonpiedra!
¿Seguro que
Queda tiempo?
Mejor acabamos,
Demo en otro momento ...

Muchas gracias por vuestra atención!
• Gracias por escucharnos!
– ¿Preguntas?
Irontec
Engineering Team
www.irontec.com
blog.irontec.com
@irontec

Escalabilidad “horizontal” en soluciones VoIP basadas en Asterisk / Kamailio

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (18)

Similar a Escalabilidad “horizontal” en soluciones VoIP basadas en Asterisk / Kamailio

Similar a Escalabilidad “horizontal” en soluciones VoIP basadas en Asterisk / Kamailio (6)

Más de Irontec

Más de Irontec (19)

Último

Último (10)

Escalabilidad “horizontal” en soluciones VoIP basadas en Asterisk / Kamailio