Diseño de PBX multitenant basada en Asterisk

DISEÑANDO UNA SOLUCIÓN
MULTI-TENANT CON ASTERISK
JON BONILLA

DISEÑANDO UNA SOLUCIÓN MULTI-TENANT CON ASTERISK
CONTEXTO
‣ VoIP2day2009: El Rombo
‣ 4K2012: Solución softswitch para operadores
‣ EW2013: Arquitecturas de operador de HostedPBX
‣ EW2014: Elastix3 (ElastixMT)
‣ EW2015: Escalabilidad de sistemas VoIP

BASADO EN HECHOS REALES
‣ PekePBX
‣ ¿Por qué tuve que desarrollarla?

OBJETIVOS
‣ Multitenant (multiempresa)
‣ Completamente orientada a ser manejada por el
usuario: 100% web.
‣ No soporte
‣ No personal cualificado

OBJETIVOS
‣ Seguro de vida: Tecnologías usadas
‣ Debian stable
‣ Asterisk 11
‣ Laravel
‣ AngularJS
‣ MySQL 
 
http://www.barnetik.com

DESARROLLO PARTE I: DB
‣ Schema DB. Conceptos y relaciones:
‣ DID, Empresa, 3 niveles de usuario y 3 niveles de
acceso
‣ Destinos y aplicaciones: Usuario, IVR, locuciones,
Sala de conferencia, Moh, Voicemail, Grupos de
extensiones, Números externos, colas de
atención… etc

DESARROLLO PARTE I: DB
‣ Ast_cdr
‣ Ast_musiconhold
‣ Ast_queues
‣ Ast_sippeers
‣ Ast_sipregs
‣ Ast_voicemail
‣ Ast_voicemail_message
‣ doctrine_migration_versions
‣ ext_log_entries
‣ ext_translations
‣ sipdoc_prefijos_internacional
‣ sipdoc_prefijos_nacional
‣ Peke_CDR
‣ Peke_Call_Record
‣ Peke_Company
‣ Peke_Company_Voicemail
‣ Peke_ConferenceRoom
‣ Peke_DID
‣ Peke_Destination
‣ Peke_Group
‣ Peke_Group_User
‣ Peke_IVR
‣ Peke_MOH
‣ Peke_Processing
‣ Peke_SoundPrompt
‣ Peke_User
‣ Peke_User_Voicemail

DESARROLLO PARTE II: LA WEB
‣ Web MINIMALISTA. No FreePBX
‣ No doc!
‣ Cada rol tiene sus tareas. 3 niveles de acceso
‣ Minimiza las opciones
‣ Responsive!
‣ Dos objetivos: Vender y evitar soporte

‣ Administrador de empresa: Le gustan los colores y
las animaciones.
‣ Lo más importante es la configuración de entrantes
INTUITIVA. Son muchas opciones y a más
opciones más fácil es complicar la web.
‣ Recordamos objetivo: No debe tener que
llamarnos en el día a día.

‣ Mención aparte para el CDR
‣ El CDR VENDE
‣ Tratad por todos los medios no facturar con él.
Usad un class5 para facturar por trunk de empresa

‣ El rol usuario ha de sentirse cómodo
‣ Con el tiempo, querremos que la web de la PBX
sea un tab permanente en el browser.

DESARROLLO PARTE III: ASTERISK
‣ La configuración se adapta a la web, al db
schema.
‣ Tenemos toda la info en DB → Realtime
‣ ODBC por supuesto
‣ Elegimos Asterisk 11. Y puede que nos
arrepintamos
‣ Cuanto menos carguemos menos cosas pueden
fallar: modules.conf

‣ Dialplan
‣ No tiene sentido tener un contexto por empresa.
Debemos separar a nivel de variable
‣ Las entrantes no se pueden discriminar por trunk. Hay
que hacerlo por DID
‣ => Dialplan unificado para todas las empresas.
‣ from-pstn
‣ from-users

‣ Dialplan
‣ Tenemos que estar leyendo configuraciones en base
de datos continuamente
‣ La mayor parte de las lecturas de DB no requieren
tratamientos complejos sino setear variables de canal
‣ => func_odbc

[from-pstn]
exten => _X.,1,Verbose(Llamada entrante desde la PSTN ${CHANNEL(peername)} al número ${EXTEN})
same => n,Set(CDR(type)=incoming)
same => n,Set(CDR(src_callerid)=${CALLERID(num)})
same => n,Set(CDR(dst_dialed)=${EXTEN})
same => n,Gosub(sub_geolocation_caller,start,1)
same => n,Set(ARRAY(EMPRESA,DIDCUSTOM,DIDID)=${ODBC_DIDEMPRESA(${EXTEN})})
same => n,GotoIf($[${EXISTS(${EMPRESA})}]?:noasignado,1)
same => n,Set(CDR(dst_company)=${EMPRESA})
same => n,Verbose(El DID está asignado a la empresa ${EMPRESA})
same => n,GoSub(sub_record_call,start,1(${EMPRESA},${CDR(type)},${EXTEN},${CALLERID(num)}))
same => n,GotoIf($["${DIDCUSTOM}" == "1"]?sub_custom_${EMPRESA}_${EXTEN},start,1)
same => n,Set(IDTRATAMIENTO=${ODBC_DIDCONFIGURED(${DIDID})})
same => n,GotoIf($[${EXISTS(${IDTRATAMIENTO})}]?:notratamiento,1)
same => n,Agi(peke_processing.php,${IDTRATAMIENTO})
same => n,GotoIf($[${EXISTS(${PROMPT})}]?:destino)
same => n,Playback(${SOUNDPATH}/${EMPRESA}/${PROMPT})
same => n(destino),GoSub(sub_destination,start,1(${EMPRESA},${DESTINATION}))
exten => noasignado,1,Verbose(DID no encontrado o no asignado a empresa)
same => n,Hangup()
exten => notratamiento,1,Verbose(DID no está conﬁgurado)
same => n,Hangup()

RELEASES
‣ Tenemos la ventaja de controlar todo el
ecosistema. Podemos hacer releases y upgrades
de forma muy sencilla: Hagamos muchas y
pequeñas.
‣ Las nuevas funcionalidades han de venir
determinadas por la necesidad de la solución y no
por la necesidad de una empresa o la de un
comercial. Hay que saber decir NO

RELEASES
‣ Asume que vas a reescribir todo el dialplan al
menos dos veces. No esperes a tenerlo todo
perfecto para sacar la versión 1.0
‣ Prepara un roadmap y prepárate para no poder
cumplirlo porque el mercado te dictará las
necesidades. Sacarlo a producción es el mejor
roadmap.

FUTURAS RELEASES
‣ Cuando las funciones PBX ya estén estables y maduras…
Salgamos de la PBX y hagamos funciones diferenciadoras:
‣ Módulos:
‣ Salas de MultiVideoconferencia
‣ Chat, compartición de pantalla… centro de comunicaciones de
la empresa: Fidelización.
‣ Integración con sistema de soporte
‣ Integración con CRMs
‣ Etc...

FUTURAS RELEASES

ESCALABILIDAD
‣ Limitados por: CAPS, Registros, Keepalives
‣ Sacamos los registros a un proxy
‣ Balanceamos los usuarios por nodo de PBX
‣ Sacamos la DB a exterior y compartimos entre todos
los nodos
‣ Sacamos la web al exterior
‣ => Proxy lb/registrar + MySQL + Web Server + N
nodos asterisk para escalar

ESCALABILIDAD

PREGUNTAS?
Jon Bonilla
manwe@sipdoc.net
@jbmanwe

Diseño de PBX multitenant basada en Asterisk

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Diseño de PBX multitenant basada en Asterisk

Similar a Diseño de PBX multitenant basada en Asterisk (20)

Último

Último (7)

Diseño de PBX multitenant basada en Asterisk