Ir al contenido

Sin categoría

vLine Wins Audience Choice and Best Conferencing Awards at WebRTC Expo

Una de las decisiones más difíciles que debe tomar una startup es cuánto tiempo y esfuerzo dedicar al desarrollo del producto frente a su promoción. Durante la mayor parte de los últimos dos años, decidimos centrarnos por completo en el desarrollo. 

Como resultado, cuando nos presentamos en la WebRTC Expo en Atlanta la semana pasada, mucha gente en la comunidad WebRTC no había oído hablar de nosotros. Eso hizo que fuera aún más gratificante salir de la conferencia con ambos Premio del Público, que fue otorgado en base a la votación de los participantes de la conferencia, y el Premio a la Mejor Organización de Conferencias, que fue premiado por un jurado como la mejor solución de videoconferencia multiparticipante.

Si te perdiste la conferencia, puedes vernos en los siguientes vídeos (cortesía de TMCNet):

Y gracias a todos los que pasaron por nuestro stand y se llevaron un #webrtcisready camiseta. Conocimos a mucha gente estupenda y esperamos seguir manteniendo esas conversaciones.

WebRTC Digest – Week of 6/24 – WebRTC Conference Highlights and WebKit

Conferencia WebRTC de Atlanta

La semana pasada fue la Conferencia WebRTC en Atlanta, Georgia. Proveedores, clientes y personas interesadas en aprender sobre WebRTC se reunieron durante tres días presentaciones, discusión, entrevistas y demostraciones (día uno y segundo día). El último día de la conferencia, los jueces entregó premios en varias categorías.

Algunos de los asistentes escribieron resúmenes de la exposición desde sus perspectivas. Chris Koehncke, Director de Desarrollo de Negocios en Genband, está convencido de que WebRTC no es solo otra “característica”:

WebRTC es un concepto difícil de comprender para el programador promedio, y nosotros, como expertos del sector, debemos trabajar en ello. No es momento de vender, sino de educar.

Tsahi Levent-Levi, uno de los moderadores del panel de WebRTC llamado “El ciclo de la exageración”, escribió sobre su reflexiones sobre la conferencia y llegó a la conclusión de que WebRTC está listo porque

Ya existían productos reales con clientes finales reales que los utilizaban, lo cual para mí es una validación de la necesidad.

WebKit

La lista de correo de desarrollo de WebKit tenía una publicación de Danilo Cesar, Ingeniero de software en Collabora, donde mencionó que

Algunos compañeros y yo estamos trabajando en la API getUserMedia/PeerConnection para la versión de Gtk.

Desarrollador principal de KDE y Desarrollador de software sénior en Digia, Allan Jensen, respondió más tarde en el hilo con

Conozco una empresa que está trabajando en WebRTC para QtWebKit. Quieren integrarlo al proyecto principal, pero desconozco el estado actual y el cronograma.

WebRTC Digest – Week of 6/17 – WebRTC Tutorial, Skype, and VP9

Descripción general y tutorial de WebRTC

Cullen Jennings, Copresidente de RTCWeb, ofreció una buena descripción general y tutorial de WebRTC en INET Bangkok. Vídeo de la presentación Ya se ha publicado. Dura unos 80 minutos y ofrece una visión general de WebRTC, además de profundizar en algunos detalles técnicos.

Arquitectura de Skype

En respuesta a una publicación en la lista de correo, el arquitecto principal de Skype Matthew Kaufman,Se analizaron algunas de las razones por las que Skype pasó de un modelo peer-to-peer a un modelo de "supernodo dedicado" basado en servidores. Una de las razones del cambio fue la falta de fiabilidad de los supernodos, que eran principalmente máquinas Windows:

Esto resultó ser un problema cuando, no una sino dos veces, una interrupción global de la red de Skype fue causada por un error crítico en ese cliente... restablecer la red después fue doloroso y prolongado.

Otro tema que se puso de relieve fue la creciente prevalencia de los dispositivos móviles:

La red peer-to-peer Skype, y muchas de sus funciones (como la mensajería instantánea), se diseñó para un mundo donde casi todas las máquinas se alimentan mediante una toma de corriente, están conectadas a Internet de banda ancha y permanecen encendidas durante muchas horas al día.

VP9 en cromo

Apoyo para el Códec VP9, el sucesor de VP8, fue habilitado por defecto en Chromium. Es aún no disponible para usarlo como códec WebRTC, pero no creemos que pase mucho tiempo antes de que lo sea.

WebRTC Digest – Week of 6/10 – Mozilla, CubeSlam, and WebRTC Conference

Mozilla

Mozilla anunció su “Talkilla” proyecto (fuente en GitHub), que será

… permiten a los usuarios comunicarse en tiempo real mientras navegan por la web y ofrecen herramientas para compartir su experiencia en línea. Otros proveedores de servicios ofrecerán sus servicios, como por ejemplo, la posibilidad de realizar y recibir llamadas desde la red telefónica.

Además, Mozilla solicita ayuda para probar la implementación de WebRTC de Firefox este viernes (21 de junio):

Nos gustaría que utilizara la nueva versión de Firefox en su teléfono Android y en su ordenador de sobremesa o portátil, y que examinara detenidamente las últimas versiones Nightly para ayudarnos a identificar cualquier problema importante que se encuentre en nuestra implementación de WebRTC y garantizar que todas las funcionalidades incluidas en esta próxima versión estén en vías de alcanzar un estado completo de pruebas y funcionalidades.

CubeSlam

Google lanzó un divertido clon de Pong llamado “CubeSlam” que utiliza el canal de datos WebRTC. Pruébalo en cubeslam.com y consulta el código fuente en Google Code.

Conferencia y Exposición WebRTC

Estaremos en Atlanta la semana que viene para el Conferencia y Exposición WebRTC. Asegúrese de pasar a saludarnos en nuestro stand (#81). Tenemos un pase gratuito para la conferencia disponible, así que la primera persona que nos envíe una nota a [email protected] ¡Lo conseguiré!

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.