1. Introducción a
WebRTC
20 Noviembre 2012

2. Presentación
WebRTC (Real Time Communications) está llamado a ser el gran avance
tecnológico de los últimos años en el ámbito de las comunicaciones
unificadas, donde los navegadores tendrán capacidades nativas de
establecer comunicaciones de voz y vídeo.
Durante 60 minutos, Elías Pérez, Antón Román y Iago Soto nos comentarán
cuál es su visión sobre estos aspectos y cómo es la mejor manera de
incorporar WebRTC a los sistemas actuales desplegados en grandes
organizaciones.
Elías Pérez Carrera Iago Soto Mata Antón Román
CEO CMO CTO
@epcarrera @iagosoto @antonroman
elias.perez@quobis.com iago.soto@quobis.com anton.roman@quobis.com

3. Agenda
- Introducción a HTML5 y WebRTC
- Arquitecturas de red
- Retos técnicos
- Casos de aplicación
- Demo
- Gestión de identidades
- Preguntas y respuestas

4. HTML5 y WebRTC. Introducción
... es la quinta revisión del lenguaje HTML,
aportando nuevas capacidades en la creación de
páginas web, especialmente en lo que se refiere
a la creación de elementos dinámicos.
Define WebSockets como nuevo protocolo de
transporte entre browser y servidor
Está promovido por el W3C
... es un proyecto opensource que aporta
capacidades de comunicación multimedia a los
navegadores web mediante simples API's en
Javascript, de manera nativa.
Está promovido por el equipo de Google Chrome

5. HTML5 y WebRTC. Estándares
Dos actores principales:
● IETF RTCWeb WG (mundo Internet)
● W3C WebRTC WG (mundo web)
Drafts:
WebRTC 1.0 Real-time Communication Between Browsers
WebRTC MediaCapture
The WebSocket API
draft-ietf-rtcweb-data-channel
draft-ietf-rtcweb-jsep
draft-ietf-rtcweb-rtp-usage
... etc ...
¡ Se están definiendo
AHORA MISMO!

6. HTML5 y WebRTC. Interés creciente

7. HTML5 y WebRTC. Ventajas
Sistema abierto, sin implementaciones propietarias
¡Sin plugins!
Multiplataforma... y ¡multidispositivo!

8. HTML5 y WebRTC. Casos de aplicación

9. HTML5 y WebRTC. Casos de aplicación

10. Arquitecturas. Browser a browser

11. Arquitecturas. Multiconference

12. Arquitecturas. Interconexión con SIP

13. Arquitecturas. Interconexión con PABX

14. Retos técnicos. Códecs
G711a/u (RFC 3551): soportado por todos los dispositivos.
Alto consumo de BW.
Tonos DTMF (RFC 4733, actualiza RFC 2833): necesarios
para interacción con muchos sistemas (p. ej. IVRs).
Opus (RFC 6716): bitrate variable, baja latencia y gran
calidad para voz humana y música. Especialmente
diseñado para comunicaciones en tiempo real.
Para interactuar con sistemas VoIP en muchos casos
será necesario transcoding o interworking de DTMFs
(RFC 4733-> INFO, RFC 4733-> in-band, etc).
Y esto sólo en los de audio...
... batalla en vídeo VP8 vs H264

15. Retos técnicos. SRTP vs DTLS-SRTP
Los equipos VoIP
normalmente
implementan la
encriptación del RTP
mediante SRTP. La clave
se intercambia en el
SDP.
DTLS-SRTP implementa un nuevo método de gestión de
la clave del SRTP. Éste se realiza mediante DTLS,
versión de TLS orientada a datagramas.

16. Retos técnicos. NAT. STUN e ICE
Los navegadores van a estar siempre tras NAT y Firewalls lo
que dificulta el intercambio de flujos de tiempo real.
El usuario quiere que la comunicación funcione siempre
(como Skype).
Es necesario encontrar un "camino" para el tráfico
RTP/RTCP independiente del escenario.
ICE, posibilita a través de los protocolos STUN y TURN, el
descubrimiento y selección de las direcciones que se van a
usar para el intercambio de flujos.
ICE fue un protocolo complejo de implementar y cuyo diseño
ha llevado varios años.

17. Retos técnicos. Negociación media
Para la negociación de la media se emplea SDP
Negociación clásica oferta-respuesta
Propuesta draft IETF:
SDP for the WebRTC / draft-nandakumar-rtcweb-sdp-00
Ejemplo SDP:
| v=0
| o=bob 16833 0 IN IP4 0.0.0.0
| s=
| t=0 0
| a=ice-ufrag:c300d85b
| a=ice-pwd:de4e99bd291c325921d5d47efbabd9
| a2
| a=fingerprint:sha-1
| 99:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:7
| 0:9d:1f:66:79:a8:07 |
| m=audio 49203 RTP/AVP 109

18. Retos técnicos. Señalización. Opciones
WebRTC no define cómo ha de gestionarse la señalización
Existen varias alternativas:
● XMPP / Jingle
● SIP
● Protocolo ad-hoc que maneje SDP's
Quobis apuesta por SIP:
● "Standard": las redes NGN se soportan sobre SIP
● "Interoperable": hay que conectarse al resto del mundo!
● "Powerful": permite construir aplicaciones por encima
Implementaciones SIP existentes:
● sipML5: primera implementación disponible
● JsSIP: autores de draft-ibc-sipcore-sip-websocket

19. Introducción a QoffeeSIP
Implementación completa de
protocolo SIP en Javascript
Se ejecuta directamente sobre
el navegador
Orientada a desarrolladores,
escrita en CoffeeScript
Fácilmente extensible
Aplicación ligera (5 KB)
Publicación opensource
en las próximas semanas

20. Introducción a QoffeeSIP
+
SIP
=
Interconexión de browsers con
el resto del equipamiento
"legacy" desplegado

21. Retos técnicos. Adopción. Browsers
Altamente involucrados en WebRTC
Primeras versiones ya estables (escritorio)
Implementa PeerConnection, GetUserMedia, etc..
Involucrados, desarrollo más lento que Chrome
Implementa ya parte del API
Iniciativa Firefox OS para móviles
Altamente involucrados en WebRTC
Primeras versiones ya estables (escritorio)
Implementa PeerConnection, GetUserMedia, etc..

22. Retos técnicos. Adopción. Browsers
Roadmap desconocido, patentes de por medio
Fundamental para móviles y tablets
Involucrados
Con propuestas propias al margen del estándar
Existe un plugin desarrollado por Google (Chrome Frame)
Desarrollado por Ericsson labs
Primer browser con WebRTC en móviles (aún sin
Websockets)
Versión beta para desarrolladores

23. Retos técnicos. Seguridad y consentimientos.
Acceso a medios: obligado consentimiento de usuario
Modelos de permiso:
● Acceso para una única sesión a cámara y micrófono
● Acceso continuado para cámara y micrófono
● Permisos basados en usuario:
○ Permitir llamadas a un usuario determinado
○ Permitir llamadas a usuarios conocidos
Indicador luminoso del acceso a cámara y micrófono
Desactivación automática cuando se pierde el foco (cambio
de pestaña)
Definido en draft-ietf-rtcweb-security

24. Retos técnicos. Monitorización.
Es posible monitorizar el tráfico
igual que se hace para SIP
estándar.
Al igual que para SIP sobre TLS,
si se usa WSS (Websocket
Seguro) la monitorización debe
hacerse en los extremos
(típicamente en el servidor).
Hemos modificado herramientas
de monitorización para poder ver
tráfico Websocket.

25. Casos de estudio. Aplicaciones
Telcos Corporaciones
SP / Social media Fabricantes

26. Casos de estudio. Aplicaciones
Telcos
● Webphone para clientes
● Integración en NGN e IMS
● Canal entrada llamadas para clientes
● Alternativa a llamadas desde
móviles

27. Casos de estudio. Aplicaciones
Corporaciones
● Click to call entrada. Nuevo canal.
● Externalizable en ourtsourcers
● Llamada por directorio interno
● Multiconferencias.
● Integración con sistemas actuales

28. Casos de estudio. Aplicaciones
SP / Social media
● Redes sociales futuros MVNOs
● Nuevos servicios para web con ID
● ISPs puedes ofrecer módulos
● Entertainment: chats, etc...

29. Casos de estudio. Aplicaciones
Fabricantes
● Online gaming
● Set-top-boxes y web TV
● Gateways WebRTC con PBX
● Fabricantes móviles

30. Demo. TalkSetup
http://TalkSetup.quobis.com

31. Demo. TalkSetup backend

32. Retos técnicos. Gestión de la identidad
Proporciona una manera de aportar
autentificación basado en un
tercero de confianza.
Añade un segundo factor de autentificación al
validar el dispositivo desde el que se llama e
introducir las credenciales securizadas en la
cabecera SIP

33. Retos técnicos. Gestión de la identidad

34. Retos técnicos. Gestión de la identidad

35. Retos técnicos. Gestión de la identidad

36. Demo. IdentityCall

37. Algunas reflexiones
● El tráfico de voz se va a la web
● El browser es un endpoint
● La web de la empresa es su call center
● El número de teléfono ya no importa (o
importa poco)
● La seguridad, identidad y privacidad es
fundamental
● Nuevas oportunidades de negocio

38. ¿Alguna pregunta?
Elías Pérez Carrera Iago Soto Mata Antón Román
CEO CMO CTO
@epcarrera @iagosoto @antonroman
elias.perez@quobis.com iago.soto@quobis.com anton.roman@quobis.com