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

Transcripción

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

2 CONTEXTO VoIP2day2009: El Rombo 4K2012: Solución softswitch para operadores EW2013: Arquitecturas de operador de HostedPBX EW2014: Elastix3 (ElastixMT) EW2015: Escalabilidad de sistemas VoIP

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

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

5 DISEÑANDO UNA SOLUCIÓN MULTI-TENANT CON ASTERISK OBJETIVOS Seguro de vida: Tecnologías usadas Debian stable Asterisk 11 Laravel AngularJS MySQL

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, Voic , Grupos de extensiones, Números externos, colas de atención etc

7 DESARROLLO PARTE I: DB Ast_cdr Ast_musiconhold Ast_queues Ast_sippeers Ast_sipregs Ast_voic Ast_voic _message Peke_CDR Peke_Call_Record Peke_Company Peke_Company_Voic Peke_ConferenceRoom Peke_DID Peke_Destination Peke_Group Peke_Group_User Peke_IVR Peke_MOH Peke_Processing Peke_SoundPrompt Peke_User Peke_User_Voic doctrine_migration_versions ext_log_entries ext_translations sipdoc_prefijos_internacional sipdoc_prefijos_nacional

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! Dos objetivos: Vender y evitar soporte

9 DESARROLLO PARTE II: LA WEB

10 DESARROLLO PARTE II: LA WEB

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 llamarnos en el día a día.

12 DESARROLLO PARTE II: LA WEB

13 DESARROLLO PARTE II: LA WEB

14 DESARROLLO PARTE II: LA WEB

15 DESARROLLO PARTE II: LA WEB

16 DESARROLLO PARTE II: LA WEB

17 DESARROLLO PARTE II: LA WEB 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

18 DESARROLLO PARTE II: LA WEB

19 DESARROLLO PARTE II: LA WEB 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.

20 DESARROLLO PARTE II: LA WEB

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 fallar: modules.conf

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 => func_odbc

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) same => n,hangup()

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 comercial. Hay que saber decir NO

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 Etc...

28 DISEÑANDO UNA SOLUCIÓN MULTI-TENANT CON ASTERISK FUTURAS RELEASES

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 nodos asterisk para escalar

30 ESCALABILIDAD

31 PREGUNTAS? Jon