WebRTC: erros comuns (iniciantes) por Tsahi Levent-Levi

WebRTC pode ser hackeado com ótimos resultados. Freqüentemente, porém, isso leva a experiências abaixo da média devido a erros básicos com WebRTC.

O WebRTC como tecnologia VoIP é a melhor coisa de todos os tempos. Ele “democratiza” todo esse domínio, levando-o das mãos de especialistas para as mãos das massas de desenvolvedores. Aplicar um pouco de código e ver um vídeo em tempo real é mágico. E agora estamos começando a adicioná-lo a mais e mais empresas que usam tecnologia da web.

Embora tudo pareça fácil agora (e é muito mais fácil do que era antes do WebRTC), existem alguns erros que muitos iniciantes cometem no WebRTC . E para ser honesto, esses erros não são cometidos apenas por iniciantes. É por isso que estou compartilhando alguns erros comuns (iniciantes) no WebRTC que tenho visto há alguns anos.

1. Usando um servidor de sinalização desatualizado (do github):

Isso acontece com muita frequência. Você começa querendo construir algo, pesquisa no github, escolhe um projeto com WebRTC - simplesmente não funciona. Pode ser para o cenário simples, mas não vai lidar com casos extremos, ou escalar bem, ou se acomodar para coisas mais complexas em que você está pensando.

A verdade é que hoje não existe um único servidor de sinalização para WebRTC pronto para uso, de código aberto, que você possa usar. Desculpe é a verdade.

Pode haver alguns concorrentes, mas não vi nenhum projeto específico que todos estejam usando (ao contrário do TURN, por exemplo, onde  COTURN definitivamente melhor). A verdade mais triste? SFUs oferecem melhor sinalização do que servidores de sinalização com WebRTC (e quase sempre eu sugiro não usar sua sinalização diretamente na frente de seu cliente WebRTC).

2. Configuração incorreta do NAT traversal

Isso deveria ter sido trivial, então, mas aparentemente não é.

Algumas regras básicas para evitar esses erros WebRTC:

1. Não conte com o Google STUN! Nunca!
2. Não use listas de servidores STUN e TURN gratuitas do github
3. Não tenha medo de implantar o TURN porque seu servidor tem um endereço IP público
4. E então, alguns, não gostam de investir, depois reclamam da tecnologia.  

Esse é um erro tão básico e comum que até criei um vídeo-curso gratuito para ele:

URL: Efetivamente Conectando Sessões WebRTC.

3. Testando localmente

Este também é um erro básico de WebRTC.

Localmente, as coisas tendem a funcionar bem. Devido à configuração de rede ser diferente da Web, mas também devido ao pó de fada que tenho certeza de que você espalha no seu roteador local (sei que faço isso todas as manhãs).

Quando você vai para o mundo real com redes reais, as coisas tendem a quebrar as suas pernas.

Teste no mundo real e não em sua máquina usando 2 guias, ou sendo profissional, use uma guia do Chrome para uma guia do Firefox. Ou vice versa.

O mundo real é confuso e confuso não é saudável para implantações ingênuas.

Precisa de ajuda para automatizar isso? Olhe para testRTC, mas não negligencie os testes do mundo real.

4. Não está usando adapter.js?

WebRTC é uma ótima especificação, mas é bastante nova.

Isso significa que:

• Navegadores diferentes irão se comportar de maneira um pouco diferente;
• As implementações do navegador apresentam alguns bugs;
• Versões diferentes do mesmo navegador agem de maneira diferente.

E ainda nem comecei a fazer com que as implementações do navegador WebRTC sejam compatíveis com as especificações 1.0.

Tudo isso se resume a você ter que elaborar uma estratégia em seu código onde todas as diretivas if/then para lidar com essas diferenças, que existem, e que vão acontecer no seu projeto.

As alternativas?

• Sempre que você encontrar tal problema, adicione a instrução if/then no código diretamente (a abordagem mais comum, embora não seja realmente inteligente a longo prazo);
• Crie um shim/polyfill/whatever, como você quiser chamá-lo, onde você faz todas essas coisas do tipo if/then (ótimo, mas não é fácil de manter)
• Basta usar o adapter.js!

Adivinha qual eu prefiro? :)

5. Esquecer de cuidar da segurança

Duas razões para você se esquecer da segurança:

• O WebRTC é seguro, então por que você deveria fazer mais alguma coisa a respeito?
• Como seu serviço não lida com pagamentos ou dados confidenciais, por que se preocupar?

Ambos os motivos não o levarão a um bom lugar. Em 2019 (e agora com a Lei do LGPD, aqui no Brasil), a segurança está em alta, principalmente nas comunicações. Você pode perguntar ao Zoom sobre isso ou verificar o Project Zero, que o google tem investido alto.

Quer um bom ponto de partida? Eu tenho um para você.

Você também pode se aprofundar e aprender muito sobre a segurança em WebRTC.

6. Supondo que você possa terceirizar tudo

Você não pode. Na verdade não.

Precisa de um design para um white paper? Um artigo escrito? Um site WordPress criado? Encontre alguém no Upwork, Fiverr ou em uma série de outros sites por aí e pronto.

Com WebRTC? Nem pense nisso.

O WebRTC está em constante mudança, o que significa que tudo o que você implantar hoje, precisará manter depois. Se você está terceirizando o trabalho - parte dele ou todo - suponha que este será um relacionamento de longo prazo e que, na maior parte, você poderá terceirizar o trabalho de desenvolvimento, mas não a responsabilidade.

Indo por este caminho? Aqui estão seis (6) coisas que você deve se perguntar antes de contratar um fornecedor/profissional terceirizado de WebRTC.

7. Mergulhar no código antes de mergulhar no WebRTC

1. Vá para o github;
2. Escolha um projeto;
3. "Instale-o;
4. Executá-lo;
5. Corrija algumas linhas de código; (acredite você vai fazer muito isto!).
6. Suponha que você tenha terminado. (mas não sonhe, não existe pó magico).

Não. WebRTC é muito mais complicado do que o cenário acima. Existem alguns servidores diferentes que você precisa implantar e usar, há uma sensibilidade geográfica a considerar e muitas outras coisas.

Você precisa entender o WebRTC se quiser realmente usá-lo corretamente. Mesmo se tudo o que você estiver fazendo for usar um terceiro. 

Não cometa esses erros WebRTC!

Certifique-se de revisar isso para ver se há algo que você está fazendo de errado:

1. Usando um servidor de sinalização desatualizado (do github);
2. Traversal de NAT com configuração incorreta;
3. Testando localmente;
4. Não usando adapter.js;
5. Esquecendo de cuidar da segurança;
6. Supondo que você possa terceirizar tudo;
7. Mergulhando no código antes de mergular no proprio WebRTC.

Confira meu curso básico WebRTC (Gratuito) ou ainda o curso avançado WebRTC, mas estude.

Eu sou Tsahi Levent-Levi. A pessoa por trás do BlogGeek.me. Este é o lugar para meus rumores sobre tecnologia. Geralmente se resume a WebRTC, CPaaS, Messaging, Disruption e outros tópicos (alguém de ficção científica?) Para colocar comida na mesa, eu também faço consultoria nesses domínios, publico meus próprios relatórios e executo um treinamento em WebRTC. Ah - e também sou cofundador e CEO da testRTC.

Se você está tentando seguir e entender os anúncios feitos em torno da tecnologia recentemente, pode notar que há muita confusão, exagero e FUD (Fake user Distortion - Distorção de Usuários Falsos/Nutrela) acontecendo. É aqui que tento desvendar essas complexidades e explicá-las da maneira mais simples que posso.

A biografia obrigatória

Durante a última década (e depois alguns) tenho participado no desenvolvimento de vários projetos de telecomunicações - principalmente aqueles relacionados a VoIP e 3G. Já fiz isso como programador, gerente, comerciante e CTO. Isso incluiu o desenvolvimento da pilha de protocolos 3G-324M do zero, bem como o gerenciamento da equipe responsável pelo desenvolvimento e manutenção da pilha de protocolos H.323, junto com outros projetos interessantes.

Atualmente, trabalho como consultor, analista e empresário em tudo relacionado a VoIP, mas com foco principalmente em CPaaS, WebRTC e seu potencial de ruptura (Tecnologias Associadas). 

Possuo mestrado em Ciência da Computação e MBA com foco em Empreendedorismo e Estratégia. Incluo em meu currículo algumas patentes e ser o presidente de diferentes grupos de atividades no IMTC - uma organização focada na interoperabilidade de padrões multimídia.

Tenho mulher e dois filhos fantásticos e adoro cozinhar. Eu escrevo aqui e como convidado em vários lugares. Você pode usar os links de mídia social na parte inferior da página (BlogGeek.me) para entrar em contato comigo ou saber mais sobre o que eu faço e onde.

Meu modelo de negócio? Having fun (Me divertindo!)