Ir al contenido

WebRTC

WebRTC Digest – Week of 6/3 – IE, Hype, and Security

¿WebRTC en Internet Explorer?

A entrada de blog y algunos tuits de una conferencia de desarrolladores de Microsoft parecía sugerir que Microsoft está progresando en WebRTC en IE (al menos en el contexto de Ejecutar Lync sin un complemento). No parece haber detalles sobre si es CU-WebRTC, vanilla WebRTC, o algo completamente distinto.

Revisión de la exageración

Mientras tanto, Cisco continuó compartiendo en su blog el artículo de la semana pasada titulado "¿La realidad de WebRTC... ¿Todo un bombo publicitario?". varios En varias ocasiones, Tsahi Levent-Levi publicó una refutación en la que afirmaba:

WebRTC es la tecnología más revolucionaria en VoIP hasta la fecha. No porque incorpore tecnología nueva, sino porque permite implementar nuevos casos de uso.

Seguridad y WebRTC

Noticias recientes Esto generó un debate sobre la seguridad y la privacidad de WebRTC. Justin Uberti, líder del equipo de WebRTC de Chrome. compartió una publicación, escrito por Adam Roach, empleado de Mozilla, que ofrece una buena visión general de los problemas: “WebRTC: Seguridad y confidencialidad”. Cullen Jennings, Empleado de Cisco y copresidente de RTCWeb, fue uno de los muchos colaboradores de un informe escrito recientemente que describe los peligros de agregar puntos finales de escuchas telefónicas a los servicios de Internet.

Tunneling WebRTC over TCP (and why it matters)

Hace un par de semanas, activamos discretamente la compatibilidad con el túnel TCP de doble extremo en la nube vLine, convirtiéndonos en los primeros Proveedor de infraestructura WebRTC para permitir la conexión a través de cortafuegos que bloquean UDP. Esto puede no parecer interesante ni importante, pero en realidad marca la diferencia entre tener un servicio que "suele conectarse" y uno que "simplemente funciona". Permítanos explicarle:

Una de las muchas cosas geniales de WebRTC es que es relativamente fácil empezar. Abra una instancia de acuerdo Para la señalización, solo hay que copiar y pegar algo de JavaScript y, ¡listo!, ya puedes hacer videollamadas en tu aplicación (en realidad, es un poco más complicado, pero un buen desarrollador web puede tener fácilmente una demostración de chat de vídeo funcionando en uno o dos días).

Lamentablemente, el camino desde la demostración hasta el servicio de producción puede ser más complicado de lo que uno espera (¡y más caro!). Así es como suele ser: 

Nivel 1: ATURDIMIENTO

Empiezas haciendo tus primeras llamadas a través de una red de área local, y todo funciona de maravilla. ¡Hurra! Luego intentas hacer una llamada a alguien fuera de tu firewall, y ocurrirá una de dos cosas.

1) Si por casualidad copiaste y pegaste la dirección del servidor STUN de Google del código fuente de apprtc, tu llamada se realizará y estarás contento (aunque es posible que tengas algunas dudas sobre si está bien usar un servicio no documentado que Google no ha dado permiso explícito a desarrolladores externos para usar. Ten en cuenta el silencio de Google sobre este hilo).

2) Si no tiene configurado un servidor STUN, su llamada fallará. Una pequeña investigación revelará que STUN es un protocolo que el navegador utiliza para determinar su dirección IP pública y abrir un agujero en el cortafuegos. Por lo tanto, si quieres conectarte a través de un cortafuegos, necesitarás un servidor STUN. Unas horas más tarde tendrás un servidor de código abierto funcionando en EC2. Una instancia pequeña debería ser suficiente ($43,92 al mes), pero probablemente querrás ejecutar al menos dos para mayor disponibilidad, preferiblemente en diferentes regiones (es decir, $87,84 al mes).

Nivel 2: TURNO

Haces algunas llamadas de prueba más y todas funcionan. Todo parece ir bien. Luego intentas hacer una llamada entre dos redes corporativas y falla. Grrr. Mientras investigabas sobre STUN, leíste sobre otro protocolo llamado TURN Se utiliza para transmitir datos cuando el navegador no puede establecer una conexión punto a punto. No estabas seguro de si era estrictamente necesario, pero una investigación más a fondo revela que STUN solo es suficiente para conectar aproximadamente 801 TP41T de llamadas. Si eso no te basta (y probablemente no lo sea), necesitarás un servidor TURN.

Algunos hilos de la lista de correo Más tarde, tendrás un servidor TURN funcionando en tu instancia EC2. En realidad, el rendimiento de la red en una instancia pequeña puede ser bastante impredecible si alguien más está usando tu interfaz de red compartida, por lo que deberías pensar en obtener una instancia más grande. Una instancia mediana ($87.84 por mes) funciona bastante bien, pero para obtener la mayor previsibilidad y la menor fluctuación, querrás una extra grande ($351.36 por mes), que te dará “alto rendimiento de la red”. En realidad, son dos ($703.52 por mes), por disponibilidad.

Por supuesto, dado que estás retransmitiendo vídeo, también tendrás que tener en cuenta los costes de ancho de banda. El precio base en EC2 es $0,12 por GB. Mientras haces los cálculos, puede que empieces a preguntarte qué impide que otra persona utilice ese servidor público que acabas de configurar y aumente tus facturas de ancho de banda. Aquí tienes una buena idea. Hilo de la lista de correo Sobre este tema. Resumen: no hay una buena manera de evitar esto dada la forma en que funciona el protocolo TURN y que las credenciales TURN deben estar presentes en su JavaScript, donde cualquiera puede encontrarlas.

Pero no nos detengamos en los detalles. Ahora puedes llamar a tus amigos de otras empresas tecnológicas. ¡Genial! Luego intentas llamar a alguien de una gran corporación que no es del sector tecnológico, y falla. ¡Maldita sea! Creías que TURN te lo ponía fácil.

20 minutos después, tras una pequeña investigación más, descubres que la implementación de asignación TURN de Chrome solo admite el reenvío de paquetes UDP. Chrome 28 añadirá soporte para asignación Un servidor TURN sobre TCP, pero los paquetes seguirán siendo retransmitidos a través de UDP. Vaya, eso no resuelve el problema cuando el cortafuegos bloquea el tráfico UDP. 

Nivel 3: Nube vLine

Aquí es donde entra en juego nuestra nueva compatibilidad con túneles TCP. No depende de la implementación TURN de Chrome, por lo que funciona en Chrome hoy mismo. Además, funciona incluso si ambas partes se encuentran detrás de cortafuegos que bloquean UDP. Lo único que se requiere es acceso a internet a través del puerto 443 (el puerto HTTPS), que la gran mayoría de los cortafuegos permiten.

No necesita hacer nada especial para habilitar el túnel TCP en su servicio vLine. Simplemente use vline.js para crear su aplicación y nos conectaremos utilizando el mejor método disponible para cada llamada. Ejecutamos un red global de servidores de alta disponibilidad, Así, brindaremos la mejor calidad de llamada posible a todos sus usuarios, en cualquier parte del mundo, incluso detrás de cortafuegos que bloquean todo excepto el tráfico TCP a través del puerto HTTPS. Por si se lo pregunta, seguimos utilizando DTLS de extremo a extremo, por lo que nuestros servidores nunca ven sus transmisiones multimedia sin cifrar.

Nuestro objetivo es una tasa de conexión de 100%. Si tiene una red donde las llamadas no se conectan, por favor háznoslo saber.

Nota 1: Si desea probar esto usted mismo bloqueando UDP en su firewall, recuerde dejar abierto el puerto DNS (53).

Nota 2: Algunos cortafuegos ultrarrestrictivos que realizan inspección de paquetes con estado aún pueden bloquear las conexiones, ya que, aunque el navegador utilice el puerto HTTPS, en realidad no está implementando SSL/TLS (nunca nos hemos encontrado con un cortafuegos así en la práctica, pero existen). Chrome pronto admitirá conexiones WebRTC a través de TLS, momento en el que también podremos sortear estos cortafuegos.

WebRTC + Chromebox = Sistema de telepresencia HD $400

WebRTC Digest – Week of 5/27 – Flow Charts, FUD, and T-Shirts

Las buenas explicaciones en profundidad de WebRTC siguen siendo escasas y distantes entre sí. Afortunadamente, Anant Narayanan de Firebase (y anteriormente el equipo de WebRTC en Mozilla) hizo una gran contribución al conjunto de presentaciones la semana pasada con su charla "Una introducción práctica a WebRTC" en la conferencia Fluent.

Asegúrate de echar un vistazo las diapositivas para el conjunto más completo de diagramas de flujo de señalización WebRTC en la web (use la flecha hacia abajo en diapositiva 7En serio, si quieres entender qué sucede internamente cuando haces clic en "Iniciar llamada" en una aplicación WebRTC, necesitas leer los diagramas de flujo. Te esperamos.

FUDdy-duddy

WebRTC fue el tema principal en No Jitter la semana pasada, con nada menos que tres publicaciones sobre el tema. Irwin Lazar de Nemertes Research comenzó con un artículo positivo titulado WebRTC: ¿Por qué debería importarles a las empresas?

Quizás lo más emocionante sea la oportunidad de dotar a las aplicaciones CRM o ERP de sus propias aplicaciones de voz/vídeo integradas directamente en sus interfaces web […] Imagínese un equipo de personas que trabajan todo el día con una aplicación de procesos empresariales y que pueden chatear, hablar o realizar videollamadas entre sí […] De nuevo, aquí las posibilidades son infinitas para que los desarrolladores de aplicaciones extiendan la comunicación y la colaboración enriquecidas a cualquier lugar.

Luego, Laurent Philonenko, vicepresidente y director general de la unidad de negocio de Clientes y Movilidad de Cisco, empañó el entusiasmo por WebRTC con el artículo "¿La realidad de WebRTC... todo un bombo publicitario?".

[…] WebRTC aún no está del todo listo para su uso generalizado. En pocas palabras, los estándares no están terminados. Supongamos que la finalización de los estándares WebRTC tardará un año, y que Chrome y Firefox tardarán seis meses en lanzar una versión con los estándares finales; además, hay que añadir el tiempo que tardan los usuarios en actualizar sus navegadores. Veremos implementaciones iniciales antes, pero diría que pasarán más de dos años antes de que esta tecnología se implemente ampliamente en el mercado.

Dave Michels concluyó con WebRTC Hype Check, explicando amablemente que no había nada que ver allí y que lo mejor era que siguieran adelante.

WebRTC no es disruptivo. […] WebRTC no ofrece nuevas funcionalidades ni ahorros de costes significativos en comparación con otras tecnologías peer-to-peer. WebRTC podría describirse con mayor precisión como una tecnología evolutiva, que incorpora capacidades en tiempo real al navegador en lugar de depender de complementos y descargas puntuales.

Por ahora, preferimos no dar detalles, pero pronto habrá más información sobre este tema en el blog de vLine. Mientras tanto, estaremos perfeccionando el diseño de nuestra nueva línea de camisetas “WebRTC está listo”.

En serio. Escríbenos Si quieres uno.

GitTogether: Video Chat for GitHub (powered by WebRTC)

tl;dr

  1. Ir a reunirse e iniciar sesión con GitHub.
  2. Consulta como contactos a las personas que sigues en GitHub, así como a los miembros de tus equipos y organizaciones.
  3. Si las personas con las que quieres hablar no están en línea o no están en tu lista de contactos, envíales tu URL de GitTogether (Gittogether GitHub).
  4. ¡Habla sin parar!

Fondo

Es difícil saber si tu plataforma es buena hasta que la hayas usado para crear una aplicación real, preferiblemente una que uses tú mismo a diario. Por eso, cuando empezamos a desarrollar la Plataforma vLine Y hace dos años, tras desarrollar la API, también empezamos a crear una aplicación sobre ella.

Dado que nuestras vidas giran prácticamente en torno a GitHub, decidimos crear una herramienta de comunicación que también lo hiciera. La llamamos GitTogether, le añadimos una cuenta de GitHub y completamos la lista de contactos con las personas a las que sigues o con las que trabajas en GitHub.

Hoy en día, contamos con una sólida aplicación que hemos estado utilizando internamente como nuestra principal herramienta de comunicación durante más de un año. Dado que nuestro objetivo principal era aprender de la experiencia de desarrollarla y usarla, nunca la compartimos ampliamente, pero suficientes personas la han descubierto y la han encontrado útil como para que decidiéramos dedicarle más tiempo a hablar de ella.

Durante las próximas semanas, publicaremos una serie de entradas en el blog explicando su funcionamiento interno, lo que aprendimos durante su desarrollo y cómo crear aplicaciones con funcionalidades similares. ¡Mientras tanto, disfrútenlas!

WebRTC Digest – Week of 5/20 – Chrome 27, Temporal Scalability & Hardware Acceleration

Cromo 27

Chrome 27 era Publicado oficialmente. A Lista de cambios relacionados con WebRTC está disponible en la lista de correo discuss-webrtc. Uno de los cambios más visibles para el usuario final es la capacidad de Seleccione la cámara y el micrófono. desde “Omnibox” en lugar de rebuscar en la configuración de Chrome.

Escalabilidad temporal

Había un una discusión interesante En la lista de correo se habló sobre la escalabilidad temporal y si se podrían exponer controles para ella en WebRTC a través de SDP, especialmente para su uso con conferencias/mezclas. La escalabilidad temporal es un método para codificar una transmisión de video en un formato que permite decodificarla a múltiples velocidades de fotogramas (por ejemplo, 30 FPS o 15 FPS) a costa de una mayor sobrecarga de codificación. Blog LifeSize proporciona una buena descripción en el contexto del códec H264, y la lista de correo de WebM tiene una descripción técnica más detallada de cómo funciona en VP8.

Aceleración de hardware

La aceleración de hardware VP8 sigue siendo compatible con más plataformas, como lo demuestra nVidia con esta demostración de Tegra 4 de videoconferencia a 1080p y 30 FPS. El Tegra 4 tendrá soporte de hardware integrado tanto para la codificación como para la decodificación de VP8, con el objetivo declarado de

Ofrecemos la mejor experiencia WebRTC en Android, Chrome OS y Google TV.

WebRTC Digest – Week of 5/13 – BB10, Firefox 22 & Google IO

WebRTC en Blackberry 10

Nuestros amigos en Hookflash comenzó la semana anunciando soporte para WebRTC en Blackberry 10. Erik Lagerway continuó en webrtc-discuss:

Quería informarles que hemos finalizado la adaptación completa de la pila multimedia WebRTC de Google a QNX/Blackberry 10. Actualmente se encuentra en nuestro repositorio de GitHub de Open Peer, y planeamos integrarla nuevamente en el repositorio principal de Google, si Google lo permite.

Justin Uberti, responsable técnico de WebRTC, celebró la noticia y estableció las reglas básicas para los puertos aportados por la comunidad:

Erik, gracias por avisarnos. ¡Siempre es bueno ver a alguien expandiendo el ecosistema WebRTC!

Si la adaptación se ajusta a nuestras directrices de estilo y a nuestras prácticas para código específico de la plataforma, podemos ayudarle a implementarla. La única salvedad es que no podremos ofrecer soporte completo a través de nuestros sistemas de prueba. Si la compilación falla, deberá solucionarlo usted mismo.

Firefox 22 Hits Beta

El martes, Firefox 21 fue liberado, lo que deja solo una versión más antes de que WebRTC esté habilitado de forma predeterminada. Firefox 22 está programado para su lanzamiento el 24 de junio.Si eres impaciente, puedes obtener una vista previa en Firefox Beta., Aurora, o si eres realmente valiente, Nocturno.

Jon Fingas, escribiendo para Engadget, tiene más información sobre Firefox 22:

Aunque Mozilla lleva tiempo defendiendo WebRTC para el chat de voz y vídeo sin necesidad de complementos, no estaba preparada para habilitar el protocolo completo en Firefox de forma predeterminada. Esta semana se muestra más segura…

Google I/O

Justin Uberti y Sam Dutton cerraron la semana con una presentación sobre WebRTC en Google IO. Tanto las diapositivas como la video Ya están disponibles para que las disfrute.

Janko Roetgers Se cubrieron los aspectos más destacados de la sesión. Para GigaOm:

WebRTC, la nueva tecnología que permite realizar chats de voz y vídeo sin necesidad de complementos directamente en el navegador, debería estar disponible en más de mil millones de dispositivos únicos (como navegadores de escritorio y dispositivos móviles) "en el plazo de una semana", según Justin Uberti, jefe de ingeniería de WebRTC de Google.

Puntos finales++

Por último, pero no por ello menos importante, Tsahi Levent-Levi tiene algunas sugerencias para los proveedores y clientes de UC en nuestra Publicación favorita de la semana:

¿Todos los sistemas y terminales de sala que está instalando? Asegúrese de que sean compatibles con WebRTC puro: que ejecuten un navegador HTML5 y que JavaScript se encargue del resto. Implemente este tipo de despliegue en su propia solución. ¿Y todos sus productos heredados? Indíqueles una puerta de enlace para que accedan al sistema.

+1 a eso.

WebRTC Digest – Week of May 6

Aquí, en la sede de vLine, tenemos una lista de correo interna que utilizamos para compartir enlaces a artículos, publicaciones de la lista de correo, revisiones de código y otros datos interesantes relacionados con WebRTC.

Ahora que por fin tenemos un blog, pensamos que sería buena idea compartir estos enlaces contigo, querido lector (¡Hola, mamá!). Así que, no te pierdas este espacio cada lunes para una nueva selección de noticias de WebRTC de la semana anterior (¡menuda actualización en tiempo real!). Sin más preámbulos, aquí tienes nuestra primera edición:

Puntos finales explosivos y arañas

Kelly Teal, escribiendo para Channel Partners, pregunta ¿Qué demonios es WebRTC? y consulta a algunos analistas para obtener respuestas:

Cuando se trata de colaboración por vídeo, todo el mundo habla de WebRTC. Pero, ¿qué es WebRTC y qué implica para los socios?

 …

“Lo que sí hace WebRTC es crear el potencial para una explosión de puntos finales de vídeo basados en navegador, que solo se conectarán a otros puntos finales que ejecuten el mismo estándar”, dijo Bill Haskins, analista de Wainhouse Research, a Channel Partners.

Sin duda, estamos de acuerdo en lo que respecta a la proliferación de puntos finales basados en navegadores. Genband, Sin embargo, discreparon en que solo se comunicarían con otros que utilizan el mismo estándar al anunciar SPiDR, una nueva puerta de enlace de compatibilidad entre protocolos antiguos y WebRTC. Gary Audin, en un artículo para NoJitter, nos cuenta la historia:

SPiDR se ubica en el extremo de la red del operador. Proporciona API abiertas y centradas en la web que permiten a los desarrolladores de aplicaciones crear servicios de comunicación avanzados a través de la red, incluyendo voz, video, información de presencia, agenda compartida, historial de llamadas, mensajería instantánea y colaboración. 

Google IO 411

El informe anual de Google fiesta de desarrolladores llegará a la ciudad a finales de esta semana, y el líder técnico de WebRTC Justin Uberti Regresará al escenario con otra sesión que seguramente llenará el recinto por completo en nuestra plataforma de simulación en tiempo real favorita (en caso de que te hayas perdido su sesión del año pasado, puedes ver el video aquí).

Este año copresentará con Chrome Developer Advocate y Colaborador de HTML5 Rocks Sam Dutton. Además, ambos dirigirán un taller práctico de programación para ayudar a los afortunados poseedores de entradas a traducir la compleja terminología de las API y los protocolos de WebRTC en atractivas aplicaciones web.

En este codelab, te ayudaremos a familiarizarte con las API y tecnologías principales de WebRTC: – MediaStream (también conocido como getUserMedia): ¿qué es y cómo puedo usarlo? – RTCPeerConnection: ¿qué tiene de importante la API más potente de WebRTC? – RTCDataChannel: ¿cómo puedo configurar la comunicación en tiempo real de datos arbitrarios? – señalización: ¿qué es y cómo la configuro? – servidores: ¿qué necesito para la señalización, STUN y TURN?

Alimento para pájaros

Hablando de delicias, Justin se preparó para IO ofreciendo un trío de bocados largamente esperados destinados a... Canario cromado en el discutir-webrtc lista de correo. El miércoles, él insinuó que pronto llegarán canales de datos confiables (si quieres ser el primero en saber cuándo llegan, puedes activar la opción de inicio de sesión). Número 1493).

Luego, el viernes, nos alegró la semana. anunciando Pronto podrás usar la API getStats() para descubrir qué candidatos ICE seleccionó el navegador. ¡Ya no tendrás que usar tcpdump ni consultar registros detallados para saber si estás usando un servidor de retransmisión! ¿Estás tan emocionado como nosotros?

Y por último, pero no menos importante, confirmó que Canary ahora tiene la capacidad de equilibrar la carga entre varios servidores TURN. Hilo completo aquí.

¿Richard Mentor Johnson?

Por último, tenemos un par de detalles relacionados con los códecs. Matt Frost, gerente de producto de WebM y ex director ejecutivo interino de On2, publicó que VP9 está cerca de completarse. No sabemos qué nos entusiasma más: la compatibilidad con canales de profundidad (cámaras web 3D + mapas de profundidad + WebGL = ???) o la guerra de códecs VP9 vs H.265.

Dado que no parece especialmente probable que los proveedores de navegadores se pongan de acuerdo en un códec integrado común en esta década, el impulso de Mozilla por un códec totalmente basado en JavaScript empieza a sonar cada vez más razonable. Siguiendo el ejemplo de Brendan Eich, Hoy vi el futuro En una publicación sobre ORBX.js, Peter Bright escribió un artículo. Bonita pieza Para Ars Technica con más detalles técnicos:

Para navegadores como Internet Explorer 10 y Safari en iOS, ORBX se utiliza en modo solo I-frame. Para otros navegadores, como Firefox y Chrome, utiliza un modo mixto más convencional. Esto se debe a que el modo mixto depende de WebGL para parte de su decodificación. Los I-frames se pueden codificar completamente en JavaScript, pero los P-frames requieren el uso de programas de sombreado debido a su mayor complejidad. Internet Explorer 10 y Safari en iOS no son compatibles con WebGL, por lo que no se pueden usar para ejecutar programas de sombreado. Como resultado, consumen aproximadamente el doble de ancho de banda para el mismo nivel de calidad de video.

Lamentablemente, aún no hay ninguna demostración pública. Pero estamos deseando probarla en nuestros iPhone 12.

Free vLine/WebRTC Consulting and Training

Una de nuestras principales prioridades es facilitar al máximo el inicio con WebRTC y la plataforma vLine. Por ello, ofrecemos cinco sesiones gratuitas de consultoría y formación de un día completo a los desarrolladores que trabajen en proyectos que utilicen WebRTC y vLine y que se lancen antes del 30 de junio.

Para los desarrolladores en Estados Unidos continental, nos desplazaremos a su oficina, nos sentaremos a su lado y haremos todo lo necesario para que su proyecto sea un éxito. Para quienes se encuentren en otras partes del mundo, haremos lo mismo mediante videollamada y compartiendo la pantalla.

Si está interesado, envíe un correo electrónico a [email protected] Cuéntanos qué estás construyendo y cómo aprovecharías el tiempo de consultoría.

El 10 de mayo revisaremos las solicitudes y seleccionaremos a los cinco desarrolladores. Se dará prioridad a los proyectos para los que ya se hayan asignado recursos de desarrollo y que se lancen próximamente.

¡Esperamos tener noticias suyas!

vLine Just Got Easier

Nos complace anunciar un hito importante para la plataforma vLine: ahora puede crear un servicio de videollamadas de marca blanca en aproximadamente un minuto, sin necesidad de escribir código.

Y para que sea aún más fácil dar el siguiente paso e integrarlo con su sitio web, estamos regalando cinco sesiones gratuitas de consultoría y capacitación presenciales de día completo para proyectos que cumplan con los requisitos (detalles completos). aquí).

Para crear tu servicio de chat de vídeo, ve a vline.com y haz clic en el botón grande "Comenzar". O para ver cómo funciona, mira este video: