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

(1)

DISEÑANDO UNA SOLUCIÓN

MULTI-TENANT CON ASTERISK

(2)

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)}

(3)

BASADO EN HECHOS REALES

‣

PekePBX

(4)

OBJETIVOS

‣

Multitenant (multiempresa)

‣

_{Completamente orientada a ser manejada por el}

usuario: 100% web.

‣

_{No soporte}

(5)

OBJETIVOS

‣

Seguro de vida: Tecnologías usadas

‣ _{Debian stable} ‣ _{Asterisk 11} ‣ _Laravel ‣ _AngularJS ‣ _MySQL   http://www.barnetik.com

(6)

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

(7)

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}

(8)

DESARROLLO PARTE II: LA WEB

‣

Web MINIMALISTA. No FreePBX

‣

_{No doc!}

‣

Cada rol tiene sus tareas. 3 niveles de acceso

‣

_{Minimiza las opciones}

‣

Responsive!

(9)

(10)

(11)

DESARROLLO PARTE II: LA WEB

‣

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}

(12)

(13)

(14)

(15)

(16)

(17)

DESARROLLO PARTE II: LA WEB

‣

Mención aparte para el CDR

‣

_{El CDR VENDE}

‣

Tratad por todos los medios no facturar con él.

(18)

(19)

DESARROLLO PARTE II: LA WEB

‣

El rol usuario ha de sentirse cómodo

‣

_{Con el tiempo, querremos que la web de la PBX}

(20)

(21)

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

(22)

DESARROLLO PARTE III: ASTERISK

‣

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

(23)

DESARROLLO PARTE III: ASTERISK

‣

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

(24)

[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á configurado)

(25)

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

(26)

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.

(27)

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}

(28)

(29)

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}

(30)

(31)

PREGUNTAS?

Jon Bonilla

[email protected]

@jbmanwe