{"id":30842,"date":"2019-10-31T21:37:44","date_gmt":"2019-10-31T18:37:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ot-skype-do-webrtc-kak-my-organizovali-videosvyaz-cherez-veb\/"},"modified":"2021-02-01T11:37:06","modified_gmt":"2021-02-01T09:37:06","slug":"ot-skype-do-webrtc-kak-my-organizovali-videosvyaz-cherez-veb","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/ot-skype-do-webrtc-kak-my-organizovali-videosvyaz-cherez-veb","title":{"rendered":"De Skype a WebRTC: como organizamos a comunica\u00e7\u00e3o de v\u00eddeo pela web","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"De<\/p>\n

A videoconfer\u00eancia \u00e9 o principal meio de comunica\u00e7\u00e3o entre professores e alunos na plataforma Vimbox. Abandonamos o Skype h\u00e1 muito tempo, testamos v\u00e1rias solu\u00e7\u00f5es de terceiros e, por fim, decidimos pela combina\u00e7\u00e3o WebRTC - Janus-gateway. Por um tempo, ficamos satisfeitos, mas algumas quest\u00f5es negativas continuaram surgindo. Como resultado, foi criada uma dire\u00e7\u00e3o separada para o v\u00eddeo.<\/p>\n

Pedi a Kirill Rogovoy, l\u00edder da nova dire\u00e7\u00e3o, que falasse sobre a evolu\u00e7\u00e3o da videoconfer\u00eancia na Skyeng, os problemas encontrados, as solu\u00e7\u00f5es e os imprevistos que acabamos aplicando. Esperamos que o artigo seja \u00fatil para empresas que tamb\u00e9m est\u00e3o integrando v\u00eddeo em suas aplica\u00e7\u00f5es web.<\/p>\n

<\/a><\/noindex><\/p>\n

Um pouco de hist\u00f3ria<\/h2>\n

No ver\u00e3o de 2017, o chefe de desenvolvimento da Skyeng, Sergey Safonov, apresentou na Backend Conf sobre como \"abandonamos o Skype e implementamos o WebRTC\". Aqueles que desejarem podem assistir \u00e0 grava\u00e7\u00e3o da apresenta\u00e7\u00e3o em link<\/a><\/noindex> (~45 min), e aqui vou resumir seu conte\u00fado.<\/p>\n

Para a escola Skyeng, a videoconfer\u00eancia sempre foi a forma priorit\u00e1ria de comunica\u00e7\u00e3o professor-aluno. No in\u00edcio, utilizava-se o Skype, mas ele n\u00e3o atendia de maneira satisfat\u00f3ria por uma s\u00e9rie de raz\u00f5es, principalmente pela falta de logs e a impossibilidade de integra\u00e7\u00e3o diretamente na aplica\u00e7\u00e3o web. Portanto, realizamos v\u00e1rias experi\u00eancias.<\/p>\n

Essencialmente, nossos requisitos para a videoconfer\u00eancia eram aproximadamente os seguintes:
\n\u2014 estabilidade;
\n\u2014 baixo custo por aula;
\n\u2014 grava\u00e7\u00e3o das aulas;
\n\u2014 monitora\u00e7\u00e3o de quem fala mais (para n\u00f3s, \u00e9 importante que os alunos falem mais que os professores durante as aulas);
\n\u2014 escalabilidade linear;
\n\u2014 a possibilidade de usar tanto UDP quanto TCP.<\/p>\n

O primeiro a ser tentado, em 2013, foi o Tokbox. Tudo estava bem, mas era muito caro - 113 rublos por aula - e isso consumia o lucro.<\/p>\n

Depois, em 2015, integramos o Voximplant. Aqui havia a fun\u00e7\u00e3o necess\u00e1ria de monitoramento de quem fala mais, e a solu\u00e7\u00e3o era significativamente mais barata: ao gravar apenas o \u00e1udio, sa\u00eda a 20 rublos por aula. No entanto, funcionava apenas via UDP, n\u00e3o conseguia mudar para TCP. Mesmo assim, no final, cerca de 40% dos alunos utilizavam.<\/p>\n

Depois de um ano, come\u00e7amos a ter clientes corporativos com suas exig\u00eancias espec\u00edficas. Por exemplo, tudo deve funcionar atrav\u00e9s do navegador, na empresa est\u00e3o dispon\u00edveis apenas http e https; ou seja, nada de 'Skypes' e UDP. Clientes corporativos = dinheiro, por isso voltamos para Tokbox, mas o problema do pre\u00e7o persistiu.<\/p>\n

A solu\u00e7\u00e3o \u2014 WebRTC e Janus<\/h2>\n

Decidimos usar a plataforma de navegador para videoconfer\u00eancia peer-to-peer WebRTC<\/a><\/noindex>. Ela gerencia a conex\u00e3o, a codifica\u00e7\u00e3o e decodifica\u00e7\u00e3o dos fluxos, a sincroniza\u00e7\u00e3o das trilhas e o controle de qualidade com o tratamento de falhas de rede. De nossa parte, precisamos garantir a captura dos fluxos da c\u00e2mera e do microfone, a renderiza\u00e7\u00e3o do v\u00eddeo, o gerenciamento da conex\u00e3o, a configura\u00e7\u00e3o da conex\u00e3o WebRTC e a transmiss\u00e3o de fluxos para ela, assim como a transmiss\u00e3o de mensagens de sinaliza\u00e7\u00e3o entre os clientes para estabelecer a conex\u00e3o (o WebRTC em si descreve apenas o formato dos dados, mas n\u00e3o o mecanismo de transmiss\u00e3o). Caso os clientes estejam por tr\u00e1s de um NAT, o WebRTC conecta servidores STUN, e se isso n\u00e3o ajudar, servidores TURN.<\/p>\n

Uma conex\u00e3o p2p comum n\u00e3o \u00e9 suficiente, pois queremos gravar as aulas para an\u00e1lise futura em caso de reclama\u00e7\u00f5es. Portanto, enviamos os fluxos WebRTC atrav\u00e9s de um retransmissor Janus Gateway da Meetecho<\/a><\/noindex>. Como resultado, os clientes n\u00e3o conhecem os endere\u00e7os uns dos outros, vendo apenas o endere\u00e7o do servidor Janus; este tamb\u00e9m desempenha as fun\u00e7\u00f5es de servidor de sinaliza\u00e7\u00e3o. O Janus possui muitas funcionalidades que precisamos: muda automaticamente para TCP se o UDP do cliente estiver bloqueado; consegue gravar fluxos tanto em UDP quanto em TCP; \u00e9 escal\u00e1vel; h\u00e1 at\u00e9 um plugin embutido para testes de eco. Se necess\u00e1rio, conectam-se automaticamente servidores STUN e TURN da Twilio.<\/p>\n

No ver\u00e3o de 2017, oper\u00e1vamos com dois servidores Janus mais um servidor adicional para processar os arquivos brutos gravados de \u00e1udio e v\u00eddeo, para n\u00e3o sobrecarregar os CPUs dos principais. Na conex\u00e3o, os servidores Janus eram escolhidos com base no princ\u00edpio par-\u00edmpar (n\u00famero de conex\u00e3o). Naquele momento, isso era suficiente e, segundo nossas percep\u00e7\u00f5es, oferecia uma margem de seguran\u00e7a de aproximadamente quatro vezes, com uma taxa de implementa\u00e7\u00e3o em torno de 80. Com isso, o custo foi reduzido para cerca de 2 rublos por aula, al\u00e9m do desenvolvimento e manuten\u00e7\u00e3o.<\/p>\n

\"De<\/p>\n

Voltando ao tema da videoconfer\u00eancia<\/h2>\n

Estamos constantemente monitorando o feedback de alunos e professores para identificar e mitigar problemas a tempo. No ver\u00e3o de 2018, a qualidade da conex\u00e3o se tornou a principal reclama\u00e7\u00e3o. Por um lado, isso significava que t\u00ednhamos lidado com outras defici\u00eancias. Por outro lado, era necess\u00e1rio agir rapidamente: com uma aula interrompida, corremos o risco de perder seu valor, \u00e0s vezes junto com o valor da compra do pr\u00f3ximo pacote, e com a interrup\u00e7\u00e3o de uma aula introdut\u00f3ria, corremos o risco de perder um cliente em potencial.<\/p>\n

Naquela \u00e9poca, nosso sistema de videoconfer\u00eancia ainda estava em modo MVP. Em termos simples, lan\u00e7amos, funcionou, escalamos uma vez, entendemos como fazer isso \u2013 e isso foi bom. If it works, don\u2019t fix it. Ningu\u00e9m estava focado na quest\u00e3o da qualidade da conex\u00e3o. Em agosto, ficou claro que isso n\u00e3o poderia continuar, e lan\u00e7amos uma nova equipe para entender o que estava errado com o WebRTC e o Janus.<\/p>\n

Essa nova equipe come\u00e7ou com: solu\u00e7\u00e3o MVP, sem m\u00e9tricas, sem objetivos, sem processos de melhoria, sendo que 7% dos professores reclamavam da qualidade da conex\u00e3o (n\u00e3o havia dados sobre os alunos, tamb\u00e9m).<\/p>\n

\"De<\/p>\n

A nova equipe come\u00e7a a trabalhar<\/h2>\n

A equipe se parece aproximadamente com isso:<\/p>\n