Somos Irontec

14 años
40 personas

Cientos de proyectos producidos con éxito
Miles de líneas de código escritas

Varios productos importantes liberados
Unos cuantos premios y reconocimientos

 

... y nosotros

Gorka Gorrotxategi

VoIP Team

Carlos Cruz

VoIP Team

Javier Infante

DEV Web Team

¿Por qué esta charla?

• Muchos años ya en la pelea, queríamos compartir el path que hemos seguido con la comunidad.
• En Irontec se mantienen muchas plataformas de voz diferentes que gestionar y evolucionar, creemos que al compartir nuestra visión aportamos bastante al caso general.
• No todas implementadas con las mismas buenas (o malas ;) ) ideas.

Antes de empezar

Os queremos contar una historia ;)

Antes de empezar

Una historia dónde los personajes son los clientes, los developers, los jefes y el señor wolf ;)

La feature "standard" entrando en escena

En el low PBX Planet:

• "Quiero que si llueve se encaminen las llamadas hacia este guarda"
• "¿Cómo que no está soportado un desvío condicional con filtrado en base a tipo, franja de tiempo, y si el número es par o impar (y que prevalezca) ?

En órbitas superiores:

• "La capa EBS tendría que tener si o si en cuenta que el status de WAN Replication está delayed antes de aceptar el deploy, es lo normal y lo esperado por un operador"
• "Lo <<normal>> es siempre aplicar las normalizaciones en el componente X.

 

Múltiples Personas

 

• Formas de entender las features diferentes.
  • Regresión / Conflictos en avances de futuros desarrollos.
  • Formas diferentes de priorizar/diferenciar lo específico de lo general.
• Enfoque comercial vs enfoque técnico.
  • Cubrir una necesidad "primordial" vs "hacer algo sostenible en el tiempo"

 

Complejidad de entornos

Fight!

• Arquitecturas HA
  • "No se puede caer nunca"
    • Con todo lo que conlleva: double ring ha, fence devices, multihoming, "ha over wan fears"
  • La filosofía KISS no siempre es la elegida.
• Multi-Protocol / Multi-All
  • Hoy por hoy, WSS, TLS, integración con legacy systems (propios o ajenos) mandatory ...
• Over Engineering (por que sí)
  • Amor al arte, pressing, probar un path "con fuego real" ... por lo que sea, pero sucede ;)

 

 

Ni siquiera el señor Lobo tiene todas las claves:

• Saber decir que no
  • Una máxima bastante repetida, casi siempre aplica (hasta que no ;) ).
• Evitar complejidad y lo específico
  •  Socializar la feature.
  • No siempre viable
• Conciencia colectiva de testing.
• Departamentos de QA

 

Hola, soy el señor Lobo, soluciono problemas.

(Pulp Fiction - 1995)

Lo aprendido

Todos en este viaje habitual concluimos que:

• Los bugs son muy probables.
• Regresiones.
• Costes.

Automated testing is cool!

¿Testing Automático en soluciones VoIP?

¿Ejército probando a ritmo de tt-monkeys?

¿Replicantes probando en loop?

Soluciones actuales open source

Aplicaciones orientadas hacia el testing (more or less):

• SIPP
• Sippy Cup
• MITESTER

SIPP

• La más conocida en general.
• Muy orientada al rendimiento.
• Realmente muy potente, pero tb compleja.
• Necesario "entender de SIP" para poder definir escenarios.
• Múltiples UAs implican múltiples procesos.

http://sipp.sourceforge.net

Sippy Cup

• Pseudo frontend/wrapper para simplificar muy mucho SIPP.
• Desarrollado en ruby.
• Es de donde hemos cogido la inspiración y muchas ideas.
• Orientado a pruebas de carga (más UAC que UAS).
• Múltiples UAs implican múltiples procesos.

http://mojolingo.github.io/sippy_cup/

MITESTER

• Disponible en SourceForge :S
• Alpha
• Última versión 2015

http://mitester.mobax.net

Ninguna nos permite probar un escenario completo

PJSUA

• Capa UA de PJLIB.
• Bindings en python.
• Muy utilizados.
• A priori, parece lo más KISS

http://www.pjsip.org/python/pjsua.htm

SIP SIMPLE CLIENT

• Desarrollado por AG Projects
• Implementa bindings en python directamente sobre PJLIB (no utiliza PJSUA).
• Podía haber sido una opción, pero para el desarrollo inicial bastaba con PJSUA.
• No se descarta migrar a SIP SIMPLE en el futuro.

http://sipsimpleclient.org

BLACK BOX SIP (BBS)

¿Qué es BBS?

Testing de Caja negra

¡Nadie garantiza que lo que pasa dentro de la caja sea lo esperado!*

* pero en función de la complejidad se puede concluir que sí ;)

e.g. bbs -v -e environment.yaml -c call.yaml

Usage

Entorno de ejecución

• Archivo separado con información sensible de cada entorno.

 

• Escrito en YAML

 

• Leído por los escenarios para:
  • Realizar llamadas SIP
  • Completar registros SIP

Escenarios

• Nombre descriptivo

• Tiempo máximo de ejecución

• Lista de sesiones del escenario
  • Cada sesión un UA y la lista de comandos a ejecutar

• Las sesiones se ejecutan en paralelo, creando tantas cuentas PJSUA como sean necesarias

Todos los comandos definidos en todas sus sesiones se ejecutan antes del tiempo máximo

Comandos

Hacer llamadas

• Iniciar llamada con Call
  • Transporte (UDP/TCP/TLS)
  • Origen a mostrar (PAI)
  • Cabeceras SIP adicionales (diversion, custom)
• Destino de llamada:
  • Número (1003)
  • URI (sip:944048182@irontec.com)
• Credentials:
  • Si las hay, llama a través de proxy y las utiliza si recibe 407.

Recibir llamadas

• Requiere registrarse Register

• Esperar llamada con WaitFor (INCOMING)

• Generar respuestas provisionales:

  • Ringing (envía 180 y espera)

• Rechazar llamada:

  • ​Busy (envía 486)
• ​Desviar llamada:

  • Redirect (envía 302)

• O contestar:

  • Verificar presentaciones:

    • CallID / Diversion OK?

  • Answer

Llamada en curso

• Enviar tonos DTMF
• Transferir llamada:
  • AttXfer​
  • BlindXfer
• Terminar llamada:
  • Hangup
  • O WaitFor (DISCONNCTD)
• Unregister

Hello, world!

• Alice espera a que Bob se registre.
• Alice llama a Bob utilizando sus credenciales.
• Bob recibe la llamada, previa verificación de que le llama Alice.
• Bob espera el colgado de Alice y se desregistra cuando lo recibe.

bbs -v -e env.yaml -c helloworld.yaml

Vale, el Hello World funciona

¿Y todo junto?

Unreal demo time

1. Alice llama desde el exterior al DID de Bob
2. Bob desvía a Charlie (1003)
3. Charlie comprueba el origen (DID Alice) y el desviador (Bob, 1002) y contesta.
4. Charlie realiza una transferencia ciega a IVR genérico (600).
5. Alice marca 1004 en el IVR.
6. Dave contesta la llamada, verificando que el origen es el DID de Alice.
7. Alice cuelga tras unos segundos.

Unreal demo time

La señalización SIP fluye...

pero... ¿las llamadas tienen audio?

y lo que cada vez es más importante... ¿webRTC?

... podemos probar las lógicas de nuestra plataforma (desvíos, IVRs, presentaciones...)

in 2017???

Browsers everywhere!

En los últimos años,  todo tiende a pasar por una navegador web:

 

- Correo electrónico (gmail vs thunderbird)

- Contenidos multimedia (mplayer vs netflix/spotify)

- Chats ( irc vs slack)

- Aplicaciones (PWA vs store apps)

- Ofimática (Google docs vs Office)

- Transparencias (slides.com vs OImpress)

 

- Softphone (JsSIP vs Bria)

 

 

 

Frontend development

• Lo más complicado a la hora de desarrollar frontend en 2017, es elegir el framework Javascript favorito:

 

 

 

(Y todos ellos son los mejores según sus usuarios)

• Y además existen un montón de herramientas de desarrollo que nos hacen la vida más fácil en los quehaceres diarios del desarrollo web.

Frontend development

• Existe un ecosistema maduro y serio en torno al desarrollo de frontend.

 

Grandes comunidades

 

 

Grandes empresas

​

 

 

 

Testing - Frontend development

Unit-testing: Pruebas simples de unidades de código; se trata de pasar (y testear) todos los casos posibles ejecutables por tu código.

 

 

 

 

 

 

 

 

 

 

 

Testing - Frontend development

 

Tests end2end: Pruebas (lo más) reales posibles, que ejecuten la aplicación como lo haría un usuario; (y que compruebe automáticamente que el comportamiento es el esperado)

 

 

 

 

 

 

Dev meets VOIP

• Julio 2012: Primer commit de JsSIP
• Septiembre 2012: Chrome soporta webrtc p2p (con prefijo -webkit)
• Mayo 2013: Firefox soporta webrtc p2p (con prefijo -moz)
• Diciembre 2013: Opera soporta webrtc
• Enero 2014: Publicación del RFC7118, una especificación con websocket como capa de transporte para la comunicación SIP entre entornos web.
• Abril 2017: Edge soporta webrtc p2p
• Septiembre 2017: Safari soporta webrtc p2p

 

¡Ya podemos desarrollar un softphone

para todos los navegadores!

 

 

Después de una pequeña prueba de concepto sin demasiado recorrido...

Telebot3000

- Testing oriented

- JsSIP based

-Self-awared

 

https://github.com/irontec/telebot3000

 

Versión pre-alpha funcional.

 

Telebot3000 - ingredientes

- angular (v5)

(sinceramente, el mejor framework del mundo)

 

- JsSIP (v3)

 

- angular-material

 

 

DEMO TIME 🎉

¿Y todo esto no es testeable?

Telebot3000 es una aplicación web normal...  ¡es testeable!

 

 

 

 

• Protractor permite describir el comportamiento de un usuario, y comprobar los cambios en el estado de la interfaz.

 

• Nos permite hacer esto de forma automática, sin necesidad de interacción humana.

 

​

¿qué probaría un humano?

- Introducir credenciales de acceso

 

 

- Pulsar el botón conectar

 

 

- Comprobar que la cara está feliz

 

 

EXTRA BALL: Llamar a la centralita de irontec, marcar la extensión 666 y esperar que la centralita cuelgue la llamada 😈.

 

e2e test - setting up

// Go to config page

await browser.get('/config');

 

element(by.css('input[formControlName=wsuri]')).sendKeys('wss://oasis-dev.irontec.com:10081');

element(by.css('input[formControlName=sipuri]')).sendKeys('webphone@oasis-dev.irontec.com');

element(by.css('input[formControlName=password]')).sendKeys('farsa');

 

element(by.css('.mat-expansion-panel-header')).click();

await browser.sleep(1000);

element(by.css('textarea[formControlName=stuns]')).sendKeys('stun:stun.l.google.com:19302');

e2e test - connecting

 

element(by.css('button.connect')).click();

await browser.sleep(2000);

 

e2e test - checking interface

 

expect(

    await element(by.css('mat-icon.ok')).isDisplayed()

).toBeTruthy();

 

EXTRA BALL: setting up

// we press 3 times '6' DTMF button

element(by.css('.dtmfMenu button[value="6"]')).click();

browser.sleep(400);

element(by.css('.dtmfMenu button[value="6"]')).click();

browser.sleep(400);

element(by.css('.dtmfMenu button[value="6"]')).click();

EXTRA BALL: checking interface

browser.sleep(1000);

expect(await element(by.css('.statusIcon')).getText()).toEqual(ICON_ENDED);

⌨️ DEMO TIME ⌨️

HTML5 APIS

Desde que apareció HTML5, tenemos un montón de APIs disponibles en el navegador, que nos permiten hacer uso de multitud de recursos distintos desde nuestra aplicació de front-end.

    - WebSocket

    - WebRTC

    - Localización, Bluetooth, MIDI, WebGL, WebAssembly, File...

    - Web Audio

• API diseñada para manipular y reproducir ficheros de sonido en el navegador.
• El audio pasa a ser una variable más en nuestra lógica, y además se integra perfectamente con WebRTC.

Telebot3000 

Telebot3000 utiliza la API WebAudio para dotar de funcionalidad extra a la interfaz de usuario (del usuario automático, se entiende).

 

• Emoticlips: Iconos sonoros transmitidos por WebRTC
• Self-awareness
  • TextToSpeech: Hablamos escribiendo.
  • SpeechToText: Escuchamos leyendo*.

 

Hacemos uso de Bing Speech API de los Servicios Cognitivos de Microsoft.

DEMO TIME 🎉

* El reconocimiento de voz tiene todavía margen de mejora.

Y todo esto, sigue siendo testeable 

• Al desplegar una nueva funcionalidad, ¿qué harían 2 humanoides para probar que todo sigue funcionando?

1. Bob llama a Alice
2. Alice descuelga a Bob
3. Bob dice "congrio rojo. congrio rojo"
4. Alice escucha "congrio rojo. congrio rojo"*

 

* es posible que Alice escuchen algo distinto.. o muy similar...

testing e2e - setting up

Protractor nos permite hacer un test con 2 instancias de navegador al mismo tiempo:

 

Haremos que la primera instancia llame a la segunda:

 

 

 

 

 

Y que la segunda simplemente responda la llamada:

 

 

  browser2 = await browser.forkNewDriverInstance(true);

// 1. dial number

await element(by.css('div.target input')).sendKeys(WEBPHONE2_DDI);

// 2. Do the call

await element(by.css('button.caller')).click();

browser2.$('button.answer').click();

testing e2e - checking UI

 

La primera instancia deberá decir "congrio rojo" (gracias al TTS de Bing):

 

 

 

 

Y la segunda (deberá esperar), y leer lo que está oyendo

 

element(by.css('input.sentence')).sendKeys('congrio rojo. congrio rojo. congrio rojo');

element(by.css('button.speakIt')).click();

Text

const listenedText = (await browser2.$$('div.words p').getText()).join(' ');

expect(

    listenedText.indexOf('congrio') !== -1 && listenedText.indexOf('rojo') !== -1

).toBeTruthy();

⌨️ DEMO TIME ⌨️

¿A dónde vamos?

 

• Es necesario un lavado de cara (aka refactor):
  • Una integración más limpia de las API de Azure
  • Repensar los módulos/componentes
  • Añadir una capa de gestión de estados inmutable (ngrx)
  • Añadir un README.md
  • ¿Dar importancia a potenciales usuarios reales?
    • Diseño/Usabilidad 
  • Estamos en versión pre-alpha!

¿A dónde vamos?

 

• A nivel funcional:
  • Mejorar rendimiento TTS
    • Actualmente la calidad conseguida es baja.
    • Dificulta el STT posterior.
  • Mejorar rendimiento STT
    • Actualmente estamos enviando ventanas de 2 segundos.
    • Es posible enviar conversación en tiempo real y tener una experincia más Real Time
  • ¿Alternativas libres?
  • Integrar pruebas de vídeo (canvas!)
• A nivel producto:
  • Softphone para personas con discapacidades sensoriales.
  • Integración de APIs de traducción - (Softphone políglota!)

¿Dónde estamos?

• Aunque estamos en una versión muy temprana de desarrollo, el software actualmente cuenta con suficiente funcionalidad desarrollada como para diseñar test e2e _bastante_ fiables.

• Los próximos pasos a dar serán:
  • Diseñar tests e2e en nuestros entornos reales.
  • Ejecución manual y depuración
  • Integración en nuestro CI PIPELINE
    • De manera que las pruebas unitarias en ese proceso se verán complementadas con las funcionalidades que hemos enseñado.

¿Y cómo encaja todo esto en el flujo de desarrollo?

1. Push en rama testing del proyecto*
2. Creación paquetes Debian con los cambios
3. Se instalan los paquetes sobre entorno de testing
4. Carga de datos de prueba vía API rest
5. Ejecución de escenarios BBS
6. Coleccionar resultados en JUnit

CI PIPELINE

Evolución

• Incluir tests de audio TELEBOT3000
• Evaluar tests sobre Pull Requests