webinar webrtc y html5 (spanish) - quobis

Introducción a WebRTC20 Noviembre 2012

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.

Iago Soto MataCMO

@iagosotoiago.soto@quobis.com

Antón RománCTO

@antonromananton.roman@quobis.com

Elías Pérez CarreraCEO

@epcarreraelias.perez@quobis.com

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

HTML5 y WebRTC. Introducción

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

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

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 BrowsersWebRTC MediaCaptureThe WebSocket APIdraft-ietf-rtcweb-data-channeldraft-ietf-rtcweb-jsepdraft-ietf-rtcweb-rtp-usage

... etc ...

¡ Se están definiendo AHORA MISMO!

HTML5 y WebRTC. Interés creciente

HTML5 y WebRTC. Ventajas

Sistema abierto, sin implementaciones propietarias

¡Sin plugins!

Multiplataforma... y ¡multidispositivo!

HTML5 y WebRTC. Casos de aplicación

HTML5 y WebRTC. Casos de aplicación

Arquitecturas. Browser a browser

Arquitecturas. Multiconference

Arquitecturas. Interconexión con SIP

Arquitecturas. Interconexión con PABX

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

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.

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.

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

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

Introducción a QoffeeSIP

Implementación completa de protocolo SIP en Javascript

Se ejecuta directamente sobreel navegador

Orientada a desarrolladores,escrita en CoffeeScript

Fácilmente extensible

Aplicación ligera (5 KB)

Publicación opensource en las próximas semanas

Introducción a QoffeeSIP

+ SIP =

Interconexión de browsers con el resto del equipamiento

"legacy" desplegado

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

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

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

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.

Casos de estudio. Aplicaciones

Telcos Corporaciones

SP / Social media Fabricantes

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

Casos de estudio. Aplicaciones

● Click to call entrada. Nuevo canal.● Externalizable en ourtsourcers● Llamada por directorio interno● Multiconferencias.● Integración con sistemas actuales

Corporaciones

Casos de estudio. Aplicaciones

● Redes sociales futuros MVNOs● Nuevos servicios para web con ID● ISPs puedes ofrecer módulos● Entertainment: chats, etc...

SP / Social media

Casos de estudio. Aplicaciones

● Online gaming● Set-top-boxes y web TV● Gateways WebRTC con PBX● Fabricantes móviles

Fabricantes

Demo. TalkSetup

http://TalkSetup.quobis.com

Demo. TalkSetup backend

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

Retos técnicos. Gestión de la identidad

Retos técnicos. Gestión de la identidad

Retos técnicos. Gestión de la identidad

Demo. IdentityCall

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

Iago Soto MataCMO

@iagosotoiago.soto@quobis.com

Antón RománCTO

@antonromananton.roman@quobis.com

Elías Pérez CarreraCEO

@epcarreraelias.perez@quobis.com

¿Alguna pregunta?