Vai al contenuto

WebRTC

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

WebRTC in Internet Explorer?

post del blog e alcuni tweet da una conferenza per sviluppatori Microsoft sembrava suggerire che Microsoft stia facendo progressi su WebRTC in IE (almeno nel contesto di eseguire Lync senza un plugin). Non sembrano esserci dettagli sul fatto che si tratti di CU-WebRTC, vanilla WebRTC, oppure qualcos'altro di completamente diverso.

Hype Recheck

Mentre Cisco continuava a ripubblicare l'articolo della scorsa settimana "La realtà di WebRTC... solo clamore?" parecchi volte, Tsahi Levent-Levi ha pubblicato una replica affermando:

WebRTC è la tecnologia più rivoluzionaria nel campo del VoIP fino ad oggi. Non perché contenga una tecnologia nuova, ma perché consente l'implementazione di nuovi casi d'uso.

Sicurezza e WebRTC

Notizie recenti ha dato origine a una discussione sulla sicurezza e la privacy di WebRTC. Il responsabile del team Chrome WebRTC, Justin Uberti ha condiviso un post, scritto dal dipendente di Mozilla Adam Roach, che fornisce una buona panoramica dei problemi: "“WebRTC: Sicurezza e riservatezza”Cullen Jennings, dipendente Cisco e co-presidente di RTCWeb, è stato uno dei tanti collaboratori di un rapporto scritto di recente che delinea i pericoli dell'aggiunta punti di intercettazione ai servizi Internet.

Tunneling WebRTC over TCP (and why it matters)

Un paio di settimane fa, abbiamo attivato silenziosamente il supporto per il tunneling TCP bidirezionale nel Cloud vLine, diventando i primi fornitore di infrastrutture WebRTC per supportare la connessione attraverso firewall che bloccano il protocollo UDP. Questo potrebbe non sembrare interessante o importante, ma in realtà fa la differenza tra avere un servizio che "di solito si connette" e uno che "funziona e basta". Vi spieghiamo perché:

Una delle tante cose fantastiche di WebRTC è che è relativamente facile da avviare. Avvia un'istanza di apprtc backend per la segnalazione, copia e incolla del codice JavaScript e, voilà, puoi effettuare videochiamate nella tua app (in realtà è un po' più complicato, ma un bravo sviluppatore web può facilmente realizzare una video chat dimostrativa funzionante in un giorno o due).

Purtroppo, il passaggio da una demo a un servizio di livello produttivo può essere più impegnativo di quanto si possa immaginare (e più costoso!). Ecco come di solito si svolge: 

Livello 1: STORDIMENTO

Si inizia effettuando le prime chiamate tramite una rete locale e tutto funziona alla perfezione. Evviva! Poi si prova a chiamare qualcuno al di fuori del firewall e possono verificarsi due situazioni.

1) Se per caso hai copiato e incollato l'indirizzo del server STUN di Google dal codice sorgente di apprtc, la tua chiamata andrà a buon fine e sarai contento (anche se potresti avere qualche dubbio persistente sul fatto che sia lecito utilizzare un servizio non documentato per il quale Google non ha dato esplicitamente il permesso agli sviluppatori di terze parti di utilizzare. Nota il silenzio di Google su questa discussione).

2) Se non hai configurato un server STUN, la tua chiamata fallirà. Una piccola ricerca rivelerà che STUN è un protocollo che il browser utilizza per determinare il proprio indirizzo IP pubblico e aprire una falla nel firewall. Quindi, se si desidera connettersi attraverso un firewall, sarà necessario un server STUN. Poche ore dopo, avrete un server open source attivo e funzionante su EC2. Una piccola istanza dovrebbe essere sufficiente ($43.92 al mese), ma probabilmente vorrete eseguirne almeno due per garantire la disponibilità, preferibilmente in regioni diverse (quindi $87.84 al mese).

Livello 2: TURNO

Esegui qualche altra chiamata di prova e funziona tutta. Le cose sembrano andare bene. Poi provi a fare una chiamata tra due reti aziendali e fallisce. Grrr. Mentre facevi ricerche su STUN, hai letto di un altro protocollo chiamato TURN Questo protocollo viene utilizzato per inoltrare i dati nei casi in cui il browser non riesce a stabilire una connessione peer-to-peer. Non eri sicuro che fosse strettamente necessario, ma ulteriori ricerche rivelano che STUN è sufficiente solo per gestire circa 80% chiamate. Se questo non ti basta (e probabilmente non lo è), avrai bisogno di un server TURN.

Alcuni discussioni della mailing list più tardi, e avrai un server TURN attivo e funzionante sulla tua istanza EC2. In realtà, la velocità di trasmissione di rete su un'istanza piccola può essere piuttosto imprevedibile, se qualcun altro sta usando la tua interfaccia di rete condivisa, quindi dovresti pensare di ottenere un'istanza più grande. Un'istanza media ($87.84 al mese) funziona abbastanza bene, ma per la massima prevedibilità e il minimo jitter, vorrai un'istanza extra large ($351.36 al mese), che ti darà "“elevate prestazioni di rete”Anzi, facciamo due ($703.52 al mese), per la disponibilità.

Naturalmente, dato che stai trasmettendo video, dovrai considerare anche i costi della larghezza di banda. Il prezzo base su EC2 è $0,12 per GB. Mentre fai i calcoli, potresti iniziare a chiederti cosa impedisce a qualcun altro di utilizzare quel server pubblico che hai appena configurato e di far lievitare le tue bollette di banda. Ecco una buona risposta. discussione sulla mailing list In merito all'argomento. Riassumendo: non esiste un modo efficace per impedirlo, dato il funzionamento del protocollo TURN e il fatto che le credenziali TURN devono essere presenti nel codice JavaScript, dove chiunque può trovarle.

Ma non perdiamoci in dettagli economici. Ora puoi chiamare i tuoi amici che lavorano in altre aziende tecnologiche. Fantastico! Poi provi a chiamare qualcuno di una grande azienda, non tecnologica, e la chiamata fallisce. Accidenti. Pensavi che TURN ti avesse protetto.

20 minuti dopo, dopo un'ulteriore ricerca, scopri che l'implementazione dell'allocazione TURN di Chrome supporta solo l'inoltro di pacchetti UDP. Chrome 28 aggiungerà il supporto per assegnazione un server TURN su TCP, ma i pacchetti verranno comunque inoltrati tramite UDP. Ops, questo non risolve ancora il tuo problema quando il firewall blocca il traffico UDP. 

Livello 3: Cloud vLine

È qui che entra in gioco il nostro nuovo supporto per il tunneling TCP. Non si basa sull'implementazione TURN di Chrome, quindi funziona già oggi in Chrome. Inoltre, funziona anche se entrambe le parti si trovano dietro firewall che bloccano UDP. Tutto ciò che serve è l'accesso a Internet tramite la porta 443 (la porta HTTPS), che la stragrande maggioranza dei firewall consente.

Non è necessario fare nulla di speciale per abilitare il tunneling TCP nel tuo servizio vLine. Basta usare vline.js per creare la tua app e ci connetteremo utilizzando il metodo migliore disponibile per ogni chiamata. Eseguiamo un rete globale di server ad alta disponibilità, In questo modo, garantiremo la migliore qualità di chiamata possibile a tutti i vostri utenti, ovunque nel mondo, anche dietro firewall che bloccano tutto tranne il traffico TCP sulla porta HTTPS. Nel caso ve lo stiate chiedendo, utilizziamo ancora la crittografia DTLS end-to-end, quindi i nostri server non visualizzano mai i vostri flussi multimediali non crittografati.

Il nostro obiettivo è un tasso di connessione di 100%. Se disponi di una rete in cui le chiamate non si connettono, per favore facci sapere.

Nota 1: Se vuoi testarlo tu stesso bloccando UDP sul tuo firewall, ricorda di lasciare aperta la porta DNS (53).

Nota 2: Alcuni firewall estremamente restrittivi che eseguono l'ispezione stateful dei pacchetti potrebbero comunque bloccare le connessioni poiché, anche se il browser utilizza la porta HTTPS, in realtà non sta eseguendo SSL/TLS (non abbiamo mai riscontrato un firewall di questo tipo nella pratica, ma esistono). Chrome supporterà presto le connessioni WebRTC su TLS, a quel punto saremo in grado di aggirare anche questi firewall.

WebRTC + Chromebox = Sistema di telepresenza HD $400

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

Le buone spiegazioni approfondite di WebRTC sono ancora rare. Fortunatamente, Anant Narayanan Di Firebase (e in precedenza membro del team WebRTC di Mozilla) ha dato un grande contributo al programma di presentazioni la scorsa settimana con il suo intervento "Un'introduzione pratica a WebRTC" alla Fluent Conference.

Assicurati di dare un'occhiata le diapositive per il set più completo di diagrammi di flusso di segnalazione WebRTC sul web (usa la freccia in basso su diapositiva 7Seriamente. Se vuoi capire cosa succede "dietro le quinte" quando fai clic su "Avvia chiamata" in un'applicazione WebRTC, devi leggere i diagrammi di flusso. Aspettiamo.

FUDdy-duddy

WebRTC è stato l'argomento principale di discussione su No Jitter la scorsa settimana, con ben tre articoli dedicati al tema. Irwin Lazar La ricerca di Nemertes è iniziata con un articolo positivo intitolato WebRTC: perché dovrebbe interessare alle aziende?

Forse ancora più interessante è l'opportunità di dotare le applicazioni CRM o ERP di proprie applicazioni vocali/video integrate direttamente nelle loro interfacce web [...] Immaginate un team di persone che lavorano tutto il giorno utilizzando un'applicazione per la gestione dei processi aziendali e che possono chattare, parlare o videochattare tra loro [...] Anche in questo caso, le opportunità per gli sviluppatori di applicazioni di estendere la comunicazione e la collaborazione avanzate ovunque sono infinite.

Poi Laurent Philonenko, vicepresidente e direttore generale della divisione Client e Mobilità di Cisco, ha smorzato l'entusiasmo per WebRTC con l'articolo "La realtà di WebRTC... è solo fumo negli occhi?".

[…] WebRTC non è ancora del tutto pronto per l'uso su larga scala. In parole semplici, gli standard non sono ancora definiti. Ipotizziamo che il completamento degli standard WebRTC richieda ancora un anno e che Chrome e Firefox impieghino sei mesi per rilasciare un browser con gli standard definitivi; a questo aggiungiamo il tempo necessario agli utenti per aggiornare i propri browser. Vedremo le prime implementazioni prima, ma direi che ci vorranno almeno due anni prima che questa tecnologia sia ampiamente diffusa sul mercato.

Dave Michels ha concluso con WebRTC Hype Check, spiegando gentilmente che non c'è niente da vedere e che fareste meglio ad andare avanti.

WebRTC non è una tecnologia dirompente. […] WebRTC non offre nuove funzionalità, né significativi risparmi sui costi rispetto ad altre tecnologie peer-to-peer. WebRTC potrebbe essere descritto più accuratamente come una tecnologia evolutiva, che di fatto porta le funzionalità in tempo reale direttamente nel browser, eliminando la necessità di plugin e download ad hoc.

Per ora preferiamo non svelare troppo, ma potete aspettarvi ulteriori aggiornamenti su questo argomento qui sul blog vLine. Nel frattempo, perfezioneremo il design della nostra nuova linea di magliette "WebRTC Is Ready".

Sul serio. Scrivici se ne desideri uno.

GitTogether: Video Chat for GitHub (powered by WebRTC)

tl;dr

  1. Vai a gittogether e accedi con GitHub.
  2. Visualizza i contatti delle persone che segui su GitHub, oltre ai membri dei tuoi team e delle tue organizzazioni.
  3. Se le persone con cui vuoi parlare non sono online o non sono nella tua lista contatti, invia loro il tuo URL GitTogether (gittogether GitHub).
  4. Chiacchiera pure!

Sfondo

È difficile sapere se la tua piattaforma è valida finché non l'hai usata per costruire un'app reale, preferibilmente una che usi tu stesso quotidianamente. Quindi, quando abbiamo iniziato a sviluppare la Piattaforma vLine e API due anni fa, abbiamo anche iniziato a sviluppare un'app basata su di essa.

Visto che le nostre vite ruotano praticamente attorno a GitHub, abbiamo deciso di creare uno strumento di comunicazione che facesse altrettanto. Lo abbiamo chiamato GitTogether, gli abbiamo fornito un accesso tramite GitHub e abbiamo popolato la lista dei contatti con le persone che segui o con cui collabori su GitHub.

Oggi, a distanza di tempo, disponiamo di un'app robusta che utilizziamo internamente come principale strumento di comunicazione da oltre un anno. Poiché il nostro obiettivo principale era imparare dall'esperienza di sviluppo e utilizzo, non l'abbiamo mai condivisa ampiamente, ma dato che un numero sufficiente di persone l'ha scoperta e trovata utile, abbiamo pensato che fosse giunto il momento di parlarne più approfonditamente.

Nelle prossime settimane pubblicheremo una serie di articoli sul blog in cui spiegheremo come funziona internamente, cosa abbiamo imparato durante il processo di sviluppo e come potete creare app con le stesse funzionalità. Nel frattempo, buona lettura!

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

Chrome 27

Chrome 27 era rilasciato ufficialmente. UN elenco delle modifiche relative a WebRTC è disponibile sulla mailing list discuss-webrtc. Uno dei cambiamenti più evidenti per l'utente finale è la possibilità di selezionare la fotocamera e il microfono dalla “Omnibox” invece di dover cercare tra le impostazioni di Chrome.

Scalabilità temporale

C'era un discussione interessante sulla mailing list riguardo alla scalabilità temporale e se i controlli per essa potrebbero essere esposti in WebRTC tramite SDP, in particolare per l'uso con conferenze/mixaggio. La scalabilità temporale è un metodo di codifica di un flusso video in un formato che consente di decodificarlo a più frame rate (ad esempio, 30 FPS o 15 FPS) a costo di un maggiore overhead di codifica. Blog LifeSize fornisce una bella descrizione nel contesto del codec H264 e la mailing list WebM ha una descrizione tecnica più dettagliata di come funziona in VP8.

Accelerazione hardware

L'accelerazione hardware VP8 continua ad essere supportata da un numero sempre maggiore di piattaforme, come dimostra nVidia con questa demo di videoconferenza a 1080p a 30 FPS su Tegra 4. Il Tegra 4 avrà il supporto hardware integrato sia per la codifica che per la decodifica VP8, con l'obiettivo dichiarato di

Offrire la migliore esperienza WebRTC su Android, Chrome OS e Google TV.

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

WebRTC su Blackberry 10

I nostri amici a Hookflash ha dato il via alla settimana annunciando il supporto per WebRTC su Blackberry 10. Erik Lagerway ha poi aggiunto su webrtc-discuss:

Volevo solo informarvi che abbiamo completato il porting dell'intero stack multimediale WebRTC di Google su QNX/Blackberry 10. Attualmente è disponibile nel nostro repository GitHub Open Peer e prevediamo di integrarlo nel progetto principale, se Google lo accetterà.

Justin Uberti, responsabile tecnico di WebRTC, ha accolto con favore la notizia e ha definito le regole di base per le versioni contribuite:

Erik, grazie per avercelo fatto sapere. È sempre un piacere vedere qualcuno che contribuisce all'espansione dell'ecosistema WebRTC!

A condizione che il porting rispetti le nostre linee guida di stile e le nostre prassi per il codice specifico della piattaforma, possiamo contribuire alla sua implementazione. L'unico inconveniente è che non saremo in grado di fornire un supporto completo tramite i nostri trybot e test. In caso di errore durante la compilazione, sarà necessario correggerlo.

Firefox 22 Hits Beta

Martedì, Firefox 21 è stato rilasciato, il che significa che manca solo una versione prima che WebRTC sia abilitato di default. Firefox 22 è attualmente previsto per il rilascio il 24 giugno. Se sei impaziente, puoi ottenere un'anteprima in Firefox Beta, Aurora, oppure se sei davvero coraggioso, Ogni notte.

Jon Fingas, scrivendo per Engadget, Ulteriori informazioni su Firefox 22:

Sebbene Mozilla sia da tempo un sostenitore di WebRTC per le chat vocali e video senza plugin, non era ancora pronta ad abilitare il protocollo completo in Firefox come standard. Da questa settimana, però, si sente più sicura...

Google IO

Justin Uberti e Sam Dutton hanno concluso la settimana con una presentazione su WebRTC al Google IO. Sia le slide che il video sono ora disponibili per la visione.

Janko Roetgers sono stati riassunti i punti salienti della sessione. per GigaOm:

Secondo Justin Uberti, responsabile del team WebRTC di Google, WebRTC, la nuova tecnologia che consente chat vocali e video senza plugin direttamente nel browser, dovrebbe essere disponibile su oltre un miliardo di dispositivi unici (come browser desktop e dispositivi mobili) "entro una settimana".

Endpoint++

Ultimo ma non meno importante, Tsahi Levent-Levi ha alcuni suggerimenti per i fornitori e i clienti di UC nel nostro Post preferito della settimana:

Tutti i sistemi e gli endpoint delle sale riunioni che state installando? Rendeteli completamente compatibili con WebRTC: fate in modo che eseguano un browser HTML5 e lasciate che JavaScript si occupi del resto. Fate in modo che la vostra soluzione utilizzi questo tipo di implementazione. E tutti i vostri prodotti legacy? Create un gateway che permetta loro di accedere al sistema.

Concordo pienamente.

WebRTC Digest – Week of May 6

Qui alla sede centrale di vLine, utilizziamo una mailing list interna per condividere link ad articoli, messaggi, commit di codice e altre informazioni interessanti relative a WebRTC.

Ora che finalmente abbiamo un blog, abbiamo pensato che sarebbe stato carino condividere questi link con voi, cari lettori (Ciao mamma!). Quindi, tenete d'occhio questa pagina ogni lunedì per una nuova selezione accuratamente curata di notizie WebRTC della settimana precedente (che ne dite di questo, in tempo reale?). Senza ulteriori indugi, ecco la nostra prima edizione:

Endpoint esplosivi e spider

Kelly Teal, scrivendo per Channel Partners, si chiede "Che cos'è WebRTC?" e interpella alcuni analisti per ottenere delle risposte:

Quando si parla di collaborazione video, tutti parlano di WebRTC. Ma cos'è WebRTC e cosa significa per i partner?

 …

“"Ciò che WebRTC fa è creare il potenziale per un'esplosione di endpoint video basati su browser, che si connetteranno solo ad altri endpoint che utilizzano lo stesso standard", ha dichiarato Bill Haskins, analista di Wainhouse Research, a Channel Partners.

Siamo assolutamente d'accordo sulla proliferazione degli endpoint basati su browser. Genband, Tuttavia, hanno contestato l'affermazione secondo cui avrebbero comunicato solo con altri che utilizzano lo stesso standard, annunciando SPiDR, un nuovo gateway da legacy a WebRTC. Gary Audin, scrivendo per NoJitter, racconta la storia:

SPiDR si posiziona ai margini della rete dell'operatore. Fornisce API aperte e orientate al web che consentono agli sviluppatori di applicazioni di creare servizi di comunicazione avanzati attraverso la rete, tra cui voce, video, presenza, rubrica condivisa, cronologia delle chiamate, messaggistica istantanea e collaborazione. 

Google IO 411

L'annuale di Google festa degli sviluppatori arriverà in città entro la fine di questa settimana, e il responsabile tecnico di WebRTC Justin Uberti tornerà sul palco con un'altra sessione che sicuramente farà il tutto esaurito sul nostro stack in tempo reale preferito (nel caso in cui vi siate persi la sua sessione dell'anno scorso, potete guardare il video qui).

Quest'anno presenterà insieme a Chrome Developer Advocate e Collaboratore di HTML5 Rocks Sam Dutton. I due terranno anche un laboratorio di programmazione pratico (Code Lab) per aiutare i fortunati possessori dei biglietti a tradurre la miriade di sigle e codici delle API e dei protocolli WebRTC in applicazioni web di successo.

In questo codelab, ti aiuteremo a familiarizzare con le API e le tecnologie principali di WebRTC: – MediaStream (anche noto come getUserMedia): cos'è e come si usa? – RTCPeerConnection: qual è l'importanza dell'API più potente di WebRTC? – RTCDataChannel: come si configura la comunicazione in tempo reale di dati arbitrari? – Segnalazione: cos'è e come si configura? – Server: di cosa ho bisogno per la segnalazione, STUN e TURN?

Cibo per uccelli

Parlando di prelibatezze gustose, Justin si è riscaldato per IO distribuendo un trio di bocconcini a lungo attesi destinati a Marrone cromato sulla discuss-webrtc lista di distribuzione. Mercoledì, lui accennato che canali dati affidabili arriveranno presto (se vuoi essere il primo a sapere quando arriveranno, puoi iniziare Numero 1493).

Poi venerdì ha reso la nostra settimana annunciando Presto potrete utilizzare l'API getStats() per scoprire quali candidati ICE sono stati selezionati dal browser. Niente più tcpdump o log dettagliati per capire se state utilizzando un server relay! Siete emozionati quanto noi?

Infine, ma non meno importante, ha confermato che Canary ha acquisito la capacità di bilanciare il carico su più server TURN. Discussione completa Qui.

Richard Mentor Johnson?

Infine, abbiamo un paio di curiosità relative ai codec. Matt Frost, Product Manager di WebM ed ex CEO ad interim di On2, ha pubblicato che VP9 è quasi completato. Non sappiamo cosa ci entusiasmi di più: il supporto per i canali di profondità (webcam 3D + mappe di profondità + WebGL = ???) o la guerra dei codec VP9 contro H.265.

Poiché non sembra particolarmente probabile che i produttori di browser si accordino su un codec integrato comune in questo decennio, la spinta di Mozilla per un codec interamente basato su JavaScript sta iniziando a sembrare sempre più ragionevole. Seguendo le orme di Brendan Eich Oggi ho visto il futuro post su ORBX.js, Peter Bright, ha scritto un bel pezzo Per Ars Technica, con maggiori dettagli tecnici:

Per i browser come Internet Explorer 10 e Safari su iOS, ORBX viene utilizzato in modalità solo I-frame. Per altri browser, tra cui Firefox e Chrome, viene utilizzata una modalità mista più convenzionale. Questo perché la modalità mista dipende da WebGL per parte della decodifica. Gli I-frame possono essere codificati interamente in JavaScript, ma i P-frame richiedono l'uso di programmi shader a causa della loro maggiore complessità. Internet Explorer 10 e Safari su iOS non supportano WebGL e quindi non possono essere utilizzati per eseguire programmi shader. Di conseguenza, utilizzano circa il doppio della larghezza di banda per lo stesso livello di qualità video.

Purtroppo, non è ancora disponibile una demo pubblica. Ma non vediamo l'ora di provarla sui nostri iPhone 12.

Free vLine/WebRTC Consulting and Training

Una delle nostre priorità principali è rendere il più semplice possibile l'avvio con WebRTC e la piattaforma vLine. A tal fine, offriamo gratuitamente cinque sessioni di consulenza e formazione di un'intera giornata agli sviluppatori che lavorano a progetti che utilizzano WebRTC e vLine e che saranno pubblicati entro il 30 giugno.

Per gli sviluppatori negli Stati Uniti continentali, verremo nel vostro ufficio, ci siederemo accanto a voi e faremo tutto il necessario per garantire il successo del vostro progetto. Per coloro che si trovano in altre parti del mondo, faremo la stessa cosa tramite videochiamata e condivisione dello schermo.

Se sei interessato, invia un'e-mail a [email protected] Spiegaci cosa stai costruendo e come intendi utilizzare il tempo di consulenza.

Il 10 maggio esamineremo le richieste e selezioneremo i cinque sviluppatori. La priorità sarà data ai progetti per i quali sono già state allocate le risorse di sviluppo e che saranno lanciati a breve.

Attendiamo con piacere una vostra risposta!

vLine Just Got Easier

Siamo lieti di annunciare un importante traguardo per la piattaforma vLine: ora è possibile creare un servizio di video chat personalizzato in circa un minuto, senza scrivere una sola riga di codice.

E per rendere ancora più semplice il passaggio successivo e l'integrazione con il tuo sito web, offriamo cinque sessioni gratuite di consulenza e formazione in loco di un'intera giornata ai progetti idonei (dettagli completi Qui).

Per creare il tuo servizio di video chat, vai a vline.com e clicca sul grande pulsante "Inizia". Oppure, per vedere come funziona, guarda questo video: