1. WebRTC: “VoIP
también desde un
navegador”
Lic. Luis Amato Perrupato
(CCNA - CCNA Voice - CCNP Routing
exam– JNCIA – ECE - ITQ (Certificación
Cisco Networking Academy), instructor
certificado de Fundación Proydesa y
también Director comercial y project
Manager de Bitsense S.R.L, estará a
cargo del seminario.
15. Hoy
Video
Voz
Mensajería
● Propietaria
● Tenemos que pertenecer a su ecosistema
● Limitadas
16. Cual es el problema ?
No sería bueno contar con una tecnología que nos
permita comunicarnos usando
las facilidades de VOZ, VIDEO y CHAT principalmente
sin necesidad de formar
parte de este ecosistema propietario.
Y si fueran tan simples como el envío
de un mail
17. Entonces les es presentamos
●Una tecnología capas de homologar las
comunicaciones de tiempo real
●Un estándar que solo necesita como
herramienta un navegador
●Un paso sin precedente en el mundo de las
comunicaciones unificadas integrando voz,
video y mensajería en un solo estándar
●Una tecnología capaz de articular con las
infraestrucruras actuales
25. RTCWeb Working
group
Standarización de
protocolos para
comunicación multimedia
“““Standard”””
...Mas bien será....
Standarización de la API de
control del Stack
WebRTC Working
group
36. EL ABC
1. Solictud de uso de recursos.
2. Generacion de sesion. Modelo Offer-Answer SDP
¿Cuales son mis ¿Como me alcanzan? ¿Donde
capacidades? estoy?
Hablo chino mandarín,
Turco...
48. Listo por hoy....
Gracias por escuchar
Quedamos disponibles
para consultas
Notas del editor
RTC- Real time comunications Web - WEB
Hace no mucho tiempo Equipo Google Hangouts La plataforma era increible, pero habia problema un gap que sortear. El video chat Necesitaba plugins, software del lado del navegador.... Problemas: No standard, depende del navegador, depende del SO, cuestiones de seguridad, etc No habia una forma standard de implementar comunicaciones en tiempo real. OPCIONES?
Las opciones? Flash? Esta en desuso, sin soporte en android ni en IOS... tencnologia en extinción. NO Standard, Muchos problemas de Seguridad Applets de Java?, Lentos, FEOS, problemas con implementaciones especificas en linux (OpenJDK, etc). Ejemplos: Integracion Facebook-Skype... Hangouts Usan plugins, componentes.. uso exclusivo de las aplicaciones de estos proveedores... no puedo usar el plugin de google fuera de él
Hacia falta un Standard. Estos muchachos pensaron: que tal si hacemos que el videochat pertenezca al open web platform? OWP: Coleccion de tecnologias estandarizadas y mantenidas por la W3C (world wide web consortium) Eso sonaba como un desafio que implicaba lidiar con cuestiones de licencimiento y opensource, otros (muchos) desarrolladores de browsers y otros muchos players.... es un standard todos deben estar de acuerdo. Entonces Nace WebRTC
Puede que no haya quedado muy claro...
Conexiones Browser to Browser de audio y video standarizado No plugins, no componentes
Standard entre comillas → es un draft a la fecha.
Pero es importante → Trabajo en progreso Todo lo que diga hoy puede cambiar mañana. Voy a mostrar mas tarde algunos ejemplos de esto... Primera version de chrome con soporte (V23) Noviembre 2012 Primera version de chrome con soporte android: M26 6 Marzo 2013. Entrada post webrtc blog. Interoperabilidad Firefox Chrome. 4 Febrero 2013
Trabajo en progreso, posibilidades abiertas. Siempre que se requiera una comunicación de video y/o audio y/o datos entre navegadores. Soporte remoto Ventas (cliente hace click y habla con representante de ventas) Redes Sociales.
Trabajo en progreso, posibilidades abiertas. Siempre que se requiera una comunicación de video y/o audio y/o datos entre navegadores. Soporte remoto Ventas (cliente hace click y habla con representante de ventas) Redes Sociales.
Trabajo en progreso, posibilidades abiertas. Siempre que se requiera una comunicación de video y/o audio y/o datos entre navegadores. Soporte remoto Ventas (cliente hace click y habla con representante de ventas) Redes Sociales.
No soporte n participantes, trabaja el navegador Armen nuevos salones y compartan el link
Corazon de la bestia Donde trabaja w3c Donde trabaja IETF Nos centraremos mas que nada en el trabajo de la IETF Vamos por partes como dijo jack el destripador
El grafico de webrtc.org quedo algo viejo. Standard Habla de Opus e G711 Que es un codec? Algoritmo decodificador codificador... sin perdida con perdida con compresion, etc. Equalizacion de voz: Volumen, Perdida de paquetes, etc
A igual consumo de ancho de banda tiene mejor calidad que la gran mayoria de los otros codecs. Toma cosas de SILK (Skype) y CELT baja latencia
En la parte de Video, hay una pelea. No está definido el standard VP8 es desarrollado por Google H264 esta protegido por MPEG-LA hay un consorcio de empresas por detras de él
Hay requerimientos fuertes en cuanto a seguridad...Diferencia SIP Cuestiones: Solicitud de uso de los recursos de media en el cliente Que el video no pueda ser enviado a un atacante nadie pueda oir el audio. SRTP Securizacion del Flujo de media DTLS similar a TLS, pero para UDP Intercambio de llaves para SRTP Multiplexing –> flujos de audio y video en ppio por separado pero es deseable que se envien en uno solo.
Web → JS quiere iniciar sesion → pide un SDP al stack → El stack aloca los recursos y genera SDP Protocolo elegido para describir la sesion SDP Navegador pide al stack (mediante JS) un SDP, el stack lo entrega acorde a los recursos y mi ubicación El browser Debe definir que tipo de sesion tiene que iniciar a fin de poder indicarle al otro extremo. Capacidades → Codecs (solo audio, audio y video, datos?)
Ejemplo de Problema. Respuesta no trivial No es posible conocer la ubicación del browser desde Javascript... es necesario que el Stack solucione el problema.
STUN → Descubrimiento de IP por Reflexión TURN → Relay Media ICE → Busca todos los candidatos y los acomoda por orden decreciente.
Eso de Abstract signaling no me gusta nada... Como Enviamos el SDP al otro lado? Como se controla la finalizacion o modificacion de la sesion? Y ahora quien podrá defendernos?
Controlar el plano de la media Dejar a la aplicación la señalizacion---> como controlar la sesion en si. Y la IETF se lavó las manos....
No es tan asi.. La idea es que pueda utilizarse lo que la aplicación quiera/necesite. Como hago llegar el SDP al otro extremo... El Emisor podria hacer un HTTP post El receptor? Long pooling Cualquier protocolo de señalizacion SIP, XMPP, ETC.
La gran pregunta? Integracion Como hacemos funcionar esta nueva herramienta con nuestra implementación de telefonía Actual. Como cohexisten estos Segmentos?
La Respuesta SIP SIP como protocolo de señalización, transporte de SDP generado en el Browser.
La Señalizacion será SIP. Browser <---> Plataforma SIP???? Respuesta: WebSockets. WebSockets es un tecnologia que permite establecer sesiones Full Duplex (comunicación de 2 vias) Sesion permanente entre un browser y un servidor (en este caso nuestra PBX) y enviar lo que uno quiera dentro de ese canal SIP Solo define como transporte: UDP, TCP, TLS , SCTP. Habia que crear una forma de enviar SIP sobre WebSockets
Como entiende SIP el browser? Es SIP parte de WebRTC? Deben los navegadores implementar SIP? NO JSSIP API como si fuese Jquery Interactua con WebRTC, obtiene el SDP y lo envia al remoto mediante SIP
Mostrar que el softphone se registra. Mostrar que ambos estan registrados en asterisk Llamar desde el hardphone al browser.