Artigos Canal Mais Comunicação em tempo real com WebRTC
Por que eu devo ler este artigo:Uma das maiores dificuldades da maioria dos desenvolvedores web é ter de lidar com tantos protocolos, especificações e regras distintas para cada fabricante de hardware, software e middleware lançados no mercado.
Muitas vezes a inclusão de drivers, web services, softwares de meio campo, dentre outras opções para integrar as tecnologias, se torna a única opção viável, mas neste artigo veremos que o WebRTC veio para quebrar esse paradigma. Ao final deste você estará apto a criar suas aplicações e fazer uso total do poder dos browsers modernos.

Até o presente momento, várias foram as tentativas de criar plataformas híbridas e abstratas o suficiente para permitir a comunicação, em tempo real, de aplicativos entre os diversos tipos de dispositivos diferentes que existem.

Alguns esforços recentes que exploram tal conceito mais focado no universo mobile e IoT (Internet of Things, ou Internet das Coisas), tais como o Tizen ou o próprio Android, trazem consigo a possibilidade de desenvolver voltado para uma gama de hardwares dos mais diversos tipos, tamanhos e finalidades (TVs, smartphones, tablets, wearables – relógios inteligentes, óculos, etc.).

Mas todo esse aparato de tecnologia envolve uma complexidade considerável, principalmente se levarmos em conta a quantidade de fabricantes dos dispositivos, suas próprias especificações, os modelos de hardware e firmware, e, sobretudo, a forma como a web se comunica com tudo isso, uma vez que ela será o ponto de partida para essa tão sonhada padronização.

Tudo na web funciona (e deve) de forma padronizada. As especificações do W3C definem os rumos que uma dada tecnologia segue nesse universo, bem como sua morte em detrimento do nascimento de uma melhor. Ao mesmo tempo, empresas como Google, Mozilla, Facebook, Twitter, dentre outras, influenciam diretamente em tais rumos através do lançamento de novas features para os seus browsers, da submissão de novas especificações para o W3C, da criação de novos frameworks front-end (a saber, AngularJS, Bootstrap, etc.), bem como da centralização de suas comunidades de desenvolvimento.

Agora, longe das realidades do mundo móvel, imagine uma realidade onde a sua TV, seu smartphone, sua geladeira e seu computador possam se comunicar sem todas essas barreiras, em tempo real, em uma só plataforma. Imagine poder compartilhar todo tipo de dado, vídeos, chats, mensagerias entre esses dispositivos de forma integrada e rápida. Pode parecer muito futurista, mas já temos uma tecnologia que tenta abraçar esse ideal: o WebRTC (contração de Web Real Time Communication, ou Comunicação Web em Tempo Real).

O conceito de RTC já é mais antigo e tentou abraçar por muito tempo um dos maiores desafios para a web: a comunicação humana via voz e vídeo. A ideia é que ele passe a ser tão natural nas aplicações web quanto digitar um texto qualquer em um campo de input no browser. Sem isso, estamos presos às soluções separadas de terceiros que tendem a dividir cada vez mais o processo. Historicamente, o desenvolvimento desse tipo de tecnologia sempre foi custoso e complexo, requerendo tecnologias de áudio e vídeo licenciadas ou desenvolvidas dentro das próprias empresas. Entretanto, talvez o maior desafio seja integrar a tecnologia RTC com o conteúdo já existente, dados e serviços, uma vez que eles consomem muito tempo para serem submetidos a tal adaptação, principalmente no universo web.

Desde os seus primeiros passos, quando o Google comprou a empresa GIPS, a qual foi responsável pela criação de vários componentes requeridos pelo RTC, o WebRTC tem agora vários padrões abertos para comunicação em tempo real, plugins gratuitos de vídeo, áudio e comunicação de dados, além de estar presente por padrão nos browsers mais usados (Chrome, Firefox, Opera e Edge). Essa complexidade já abraça alguns casos reais, a saber:

  • Muitos serviços atualmente já usam RTC, porém necessitam downloads, apps nativas ou plugins. É o caso do Skype, Facebook (que faz uso do Skype) e Google Hangouts (que faz uso do plugin Google Talk);
  • Efetuar o download, instalação e atualização de plugins pode ser complexo, não intuitivo e complicado;
  • Plugins podem ser difíceis de depurar, efetuar deploy, encontrar soluções para eventuais erros, testar e manter (além de poderem exigir licenciamento ou integração com tecnologias mais complexas e caras).

Além disso, o próprio fato de se tratar de um plugin gera desconfiança na maioria dos usuários leigos, que não querem instalar nada de terceiros no browser, sob pena de se tratar de algum conteúdo malicioso.

Além disso, o WebRTC é usado em vários apps mobile como WhatsApp, Facebook Messenger, appear.in e algumas plataformas como a TokBox. A própria Microsoft incluir as APIs de Stream e MediaCapture no seu mais recente browser, o Edge.

Meu primeiro WebRTC

O WebRTC implementa basicamente e três APIs: MediaStream, RTCPeerConnection e RTCDataChannel.

MediaStream

A API de MediaStream é nada mais que streams de mídia sincronizados que está presente nos browsers Chrome, Opera, Firefox e Edge.

Por exemplo, uma stream de dados tirada diretamente de uma câmera ou de um microfone tem implicitamente faixas de áudio e vídeo sincronizadas (synchronized).

Não confunda as faixas de MediaStream com o elemento da HTML5 <track>, que é usado para outra finalidade. A melhor forma de entender o que é uma MediaStream é testando-o via exemplos base disponibilizados no site do projeto hospedado no GitHub. Para isso:

  • Abra a URL do demo de MediaStream (vide seção Links) no Google Chrome ou Opera;
  • Abra a ferramenta de desenvolvedor Console (use o atalho F12 para isso);
  • Inspecione a variável stream que está em escopo global (você deverá ver uma tela parecida com a ilustrada na Figura 1).

Cada MediaStream tem um input (que corresponde ao MediaStream gerado pelo método navigator.getUserMedia()), e um output (que deve ser passado sempre ao elemento de vídeo ou para um objeto do tipo RTCPeerConnection).

O método getUserMedia(), por sua vez, recebe três parâmetros, a saber:

o Um objeto de constraint;

o Uma função de callback de sucesso que, se chamada, receberá um MediaStream como parâmetro;

o Uma função de callback de falha que, se chamada, receberá um objeto de erro como parâmetro.

Cada MediaStream também tem uma label, no exemplo em questão de valor “DEKcNCAWBccPsTkgH3t6D8vcM3ZO47Ddew9g”. Além disso, um vetor de faixas de MediaStream é retornado sempre que uma chamada aos métodos getAudioTracks() e getVideoTracks() for efetuada. Contudo, a função também serve como um nó de entrada de dados para a API de Web Audio (veja na Listagem 1 um exemplo básico disso).

Variável stream inspecionada no Console
Figura 1. Variável stream inspecionada no Console.

  function recuperarStream(stream) {
      window.AudioContext = window.AudioContext || window.webkitAudioContext;
      var contextoAudio = new AudioContext();
   
      // Cria um AudioNode para o stream
      var fonteMidia = contextoAudio.createfonteMidia(stream);
   
      fonteMidia.connect(contextoAudio.destination);
  }
   
  navigator.get ...

Quer ler esse conteúdo completo? Tenha acesso completo