Este documento describe una presentación sobre pruebas automatizadas para aplicaciones VoIP y WebRTC. La presentación es dada por tres personas de la compañía Irontec con 14 años de experiencia y decenas de proyectos exitosos. La presentación explica el camino que han seguido para implementar pruebas automatizadas y compartir sus mejores prácticas con la comunidad. Se discuten varias herramientas de pruebas de código abierto y cómo ninguna cubre completamente sus necesidades, por lo que desarrollan su propia herramienta llamada Black Box SIP

1. Automated Testing
para aplicaciones
VoIP, WebRTC
Carlos Cruz
Javier Infante
Gorka Gorrotxategi

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

3. ... y nosotros
Gorka Gorrotxategi
VoIP Team
Carlos Cruz
VoIP Team
Javier Infante
DEV Web Team

4. ¿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.

5. Antes de empezar
Os queremos contar una historia ;)

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

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

8. 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"

9. 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 ;)

10. 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)

11. Lo aprendido
Todos en este viaje habitual
concluimos que:
Los bugs son muy probables.
Regresiones.
Costes.
Automated testing is cool!

12. ¿Testing Automático en soluciones VoIP?
¿Ejército probando a ritmo de tt-monkeys? ¿Replicantes probando en loop?

13. Soluciones actuales open source
Aplicaciones orientadas hacia el testing (more or less):
SIPP
Sippy Cup
MITESTER

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

15. 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/

16. MITESTER
Disponible en SourceForge :S
Alpha
Última versión 2015
http://mitester.mobax.net

17. Ninguna nos permite probar
un escenario completo
¿hacemos algo?
OK, pero que sea fácil ;)

18. PJSUA
Capa UA de PJLIB.
Bindings en python.
Muy utilizados.
A priori, parece lo más KISS
http://www.pjsip.org/python/pjsua.htm

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

20. BLACK BOX SIP (BBS)

21. ¿Qué es BBS?
Tests de caja negra definidos en YAML
https://github.com/irontec/bss
PJSUA (pjlib)
CLI tool escrita en python

22. 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í ;)

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

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

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

26. Comandos
DTMF
AttXfer
BlindXfer
Hangup
Call
Busy
Redirect
Ringing
CallID
Diversion
Answer
Register
Unregister
Wait
WaitFor

27. 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: @irontec.com)
Credentials:
Si las hay, llama a través de proxy y las
utiliza si recibe 407.
944048182

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

29. Llamada en curso
Enviar tonos DTMF
Transferir llamada:
AttXfer​
BlindXfer
Terminar llamada:
Hangup
O WaitFor (DISCONNCTD)
Unregister

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

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

32. Vale, el Hello World funciona
¿Y todo junto?

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

34. Unreal demo time

35. 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???

36. 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)

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

38. Frontend development
Existe un ecosistema maduro y serio en torno al desarrollo de frontend.
Grandes comunidades
Grandes empresas

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

40. 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)

41. 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 , 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!
RFC7118

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

43. Telebot3000
- Testing oriented
- JsSIP based
-Self-awared
https://github.com/irontec/telebot3000
Versión pre-alpha funcional.

44. Telebot3000 - ingredientes
- angular (v5)
(sinceramente, el mejor framework del mundo)
- JsSIP (v3)
- angular-material
DEMO TIME 🎉

45. ¿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.

46. ¿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 😈.

47. 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');

48. 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();

49. 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 ⌨

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

51. 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 🎉

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

53. 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();

54. 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 ⌨

55. ¿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!

56. ¿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!)

57. ¿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.

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

59. 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
BBS
CI PIPELINE
(*) Cada nueva funcionalidad, incluye escenarios yaml BBS y actualización JSON postman con nuevos objetos

60. Evolución
Incluir tests de audio TELEBOT3000
Evaluar tests sobre Pull Requests

61. ¡Muchas gracias!