O software de colaboração autoalojado suporta chamadas de voz e vídeo? Lista de verificação da prontidão da rede

Comece pelas chamadas de que a sua equipa realmente precisa

«Suporta chamadas» não é um requisito de implementação completo. Antes de comparar opções de alojamento, defina quem vai ligar a quem, que clientes utilizará e a partir de onde essas pessoas se irão ligar. Uma equipa cujos membros partilham uma rede de escritório pode enfrentar limitações diferentes das de uma equipa com convidados externos e utilizadores em ligações domésticas ou móveis.

Confirme também que funcionalidades são importantes. A voz, o vídeo, a partilha de ecrã e as chamadas com participantes externos podem ter requisitos de suporte ou configuração diferentes. O [guia de implementação do Calls do Mattermost](https://docs.mattermost.com/deployment-guide/calls/calls-deployment-guide) descreve o Calls como uma funcionalidade autoalojada para chamadas de áudio e partilha de ecrã. Essa descrição, por si só, não confirma que todos os clientes ou redes de utilizadores funcionarão no seu ambiente.

• Enumere as funcionalidades de chamada, os tipos de participantes e os tipos de cliente necessários, como o navegador ou a aplicação nativa.
• Inclua as redes que as pessoas irão utilizar: escritório, casa, rede móvel e quaisquer redes de convidados ou parceiros.
• Decida que falhas são aceitáveis. Por exemplo, é suficiente recorrer apenas ao áudio se não for possível estabelecer o vídeo?

Separe o acesso à Web, a sinalização e a multimédia

Um primeiro passo útil é consultar a documentação oficial e atual da aplicação e dividir os requisitos em percursos distintos. A interface Web é aquilo que os utilizadores carregam; a sinalização é a troca de informações utilizada para estabelecer ou gerir uma chamada; a multimédia é o tráfego de áudio e vídeo. A documentação da aplicação pode descrever estes percursos separadamente ou utilizar outra terminologia.

Conseguir iniciar sessão através de um navegador confirma o acesso à Web, mas não significa necessariamente que a configuração da chamada ou a transmissão bidirecional de multimédia funcionem. Registe os requisitos documentados para cada percurso, em vez de presumir que um site funcional comprova que as chamadas estão prontas a utilizar.

A [descrição do Talk da Nextcloud](https://nextcloud.com/blog/nextcloud-talk-open-source-online-video-conferencing-software/) identifica-o como software de videoconferência online de código aberto que suporta chats, chamadas, webinars e transmissão. Esta descrição de funcionalidades ajuda a identificar o âmbito do produto, mas não especifica, por si só, a configuração de rede necessária para os seus utilizadores.

• Procure a documentação de implementação do fornecedor para a aplicação e o modelo de implementação exatos que pretende utilizar.
• Registe separadamente os requisitos documentados para a interface Web, a sinalização das chamadas e a multimédia.
• Verifique se os requisitos variam consoante o cliente, a funcionalidade ou o componente de implementação; não preencha lacunas com suposições.

Verifique os protocolos, as portas, as firewalls, o NAT e os retransmissores

Utilize a documentação oficial para elaborar uma lista das alterações de rede necessárias. Registe os protocolos e as portas especificados, se as ligações têm de ser permitidas de entrada, de saída ou em ambos os sentidos, e que sistemas ou pontos de destino estão envolvidos. Não copie uma lista genérica de portas de outro produto de colaboração: os requisitos podem variar, e as descrições de produto disponíveis não especificam valores concretos para portas ou firewalls.

Procure a informação documentada sobre o comportamento quando os participantes estão atrás de NAT ou de firewalls restritivas. Em particular, confirme se se espera que as ligações diretas de multimédia funcionem, se um retransmissor TURN é suportado ou necessário em determinadas circunstâncias e quem o opera. Se a documentação não responder a estas perguntas, considere-as questões de implementação em aberto e consulte o fornecedor da aplicação ou do alojamento antes da implementação.

Um retransmissor pode ser uma dependência, e não um pormenor opcional. Confirme se tem de ser implementado, se precisa de estar acessível, configurado na aplicação ou ser mantido separadamente; verifique estes pontos na documentação do produto, em vez de presumir. O [guia de implementação do Calls do Mattermost](https://docs.mattermost.com/deployment-guide/calls/calls-deployment-guide) é um ponto de partida baseado numa fonte primária para o Mattermost, mas a informação disponível sobre as funcionalidades não especifica requisitos concretos de portas, NAT ou retransmissores.

• Crie uma tabela com o protocolo, a porta, o sentido do tráfego, o destino e a finalidade documentados.
• Peça aos administradores de rede que confirmem se o tráfego necessário é permitido nas redes de escritório e remotas relevantes.
• Confirme o comportamento documentado de travessia de NAT e TURN, incluindo quem é responsável pelo retransmissor e pela sua operação.
• Assinale como não verificado qualquer requisito que não esteja documentado; não considere um início de sessão bem-sucedido como prova de que o tráfego multimédia é permitido.

Verifique as suposições sobre TLS, domínios e proxies inversos

Confirme como a aplicação espera que sejam configurados o domínio público, a terminação TLS e qualquer proxy inverso. Identifique que componente gere cada ligação e se a documentação oficial indica requisitos adicionais para chamadas, além dos necessários para a interface Web. Não presuma que uma determinada configuração de proxy ou TLS é compatível com todas as funcionalidades de chamada, a menos que a documentação da aplicação o confirme.

Uma página HTTPS válida não constitui um teste completo do percurso de chamada. Pode confirmar que o ponto de acesso Web está acessível, deixando por testar os requisitos de sinalização ou multimédia. Se a arquitetura colocar um proxy à frente da aplicação, compare a arquitetura de chamadas documentada com o encaminhamento e a configuração de certificados reais e esclareça quaisquer ambiguidades antes de os utilizadores dependerem das chamadas.

A [informação sobre os produtos da Airbip](https://airbip.com) descreve o encaminhamento automatizado e os certificados TLS através do Traefik e do Let’s Encrypt, bem como o suporte para um subdomínio Airbip ou um domínio personalizado compatível. Estas funcionalidades descrevem a configuração de alojamento Web; por si só, não confirmam que as funcionalidades de chamada ou os percursos de multimédia de uma aplicação específica sejam suportados em todas as redes.

• Confirme os requisitos de domínio público e de TLS na documentação de implementação da aplicação.
• Compare a arquitetura documentada com a configuração real de proxy, DNS e certificados.
• Peça ao fornecedor ou ao vendedor relevante que esclareça quaisquer requisitos de proxy ou TLS específicos das chamadas que não estejam documentados.

Teste com utilizadores representativos, não apenas com a equipa de servidores

Depois de implementar a configuração documentada, teste-a nas redes que os seus utilizadores irão realmente utilizar. Um teste realizado no mesmo escritório ou ambiente do servidor pode não detetar restrições presentes em redes domésticas, móveis, de convidados ou de parceiros. Inclua pelo menos uma rede restritiva se esses utilizadores fizerem parte do público previsto.

Utilize uma lista de verificação repetível: os participantes conseguem iniciar e entrar numa chamada, ouvir-se mutuamente nos dois sentidos, ver o vídeo se necessário e partilhar o conteúdo pretendido? Em seguida, teste o que acontece quando uma ligação é interrompida e restabelecida. Se a aplicação indicar se está a ser utilizado um retransmissor, registe esse resultado; não deduza a utilização de um retransmissor apenas pela qualidade da chamada.

Um teste aprovado demonstra que a configuração testada funcionou para os utilizadores e as redes testados naquele momento. Não garante que a rede, o dispositivo ou as alterações posteriores à rede de todos os participantes se comportem da mesma forma. As descrições de produto citadas acima não estabelecem um procedimento de teste de rede representativo; por isso, considere esta lista uma orientação geral de implementação, não uma garantia do produto.

• Teste cada tipo de cliente necessário e as funcionalidades de chamada que a equipa pretende utilizar.
• Teste participantes em redes de escritório, domésticas, móveis e outras redes relevantes, incluindo ambientes restritivos sempre que possível.
• Registe o estabelecimento da chamada, o áudio bidirecional, o vídeo, a partilha de ecrã se necessária, a reconexão e o comportamento documentado do retransmissor.
• Guarde a data, o tipo de cliente, o contexto de rede e o resultado para poder comparar os resultados após alterações.

Escolha um modelo de implementação com base em requisitos verificados

Compare as opções de alojamento apenas depois de conhecer os requisitos documentados da aplicação e saber que controlos de rede consegue obter. Considere se pode configurar as regras de firewall necessárias, operar ou obter qualquer serviço de retransmissão obrigatório e investigar falhas nas diferentes redes dos utilizadores.

Uma implementação gerida da aplicação pode tratar de algumas partes da infraestrutura que a envolve, mas isso não confirma automaticamente o suporte de todas as funcionalidades de chamada ou percursos de rede. A [informação sobre os produtos da Airbip](https://airbip.com) descreve instâncias de aplicações executadas como cargas de trabalho Docker nos seus servidores na nuvem, bem como a gestão do ciclo de vida do serviço, verificações de DNS e cópias de segurança diárias, semanais e mensais configuráveis. Avalie estas funcionalidades em conjunto com os requisitos específicos das chamadas confirmados na documentação da aplicação, e não em substituição desses requisitos.

Se a sua equipa não puder fornecer um controlo de rede ou um serviço de retransmissão necessário, ou não conseguir lidar com a diversidade das redes dos utilizadores, outro modelo de implementação ou um serviço concebido para o caso de utilização poderá ser mais adequado. Tome essa decisão com base nos requisitos verificados, não na existência de um botão de chamada ou num início de sessão Web bem-sucedido.

• Atribua cada requisito documentado a um responsável: a sua equipa, o fornecedor do alojamento ou o vendedor da aplicação.
• Confirme todas as dependências de retransmissores e de controlo de rede antes de se comprometer com uma implementação.
• Escolha outro modelo se não for possível satisfazer uma funcionalidade ou responsabilidade operacional necessária.

Documente as responsabilidades e volte a testar após alterações

Mantenha um registo conciso da arquitetura, dos protocolos e das portas documentados, da configuração de DNS e TLS, da configuração do proxy, das dependências de retransmissores e dos responsáveis por cada alteração. Inclua um procedimento de resolução de problemas para que os utilizadores saibam onde comunicar falhas e os administradores possam distinguir problemas de acesso à Web de problemas de configuração de chamadas ou de multimédia.

Planeie repetir os testes com utilizadores representativos após alterações à aplicação, ao alojamento, ao proxy, à firewall, ao retransmissor ou à rede dos utilizadores. Uma verificação documentada e repetível é mais útil do que tratar uma única reunião bem-sucedida como uma garantia permanente.

• Registe a documentação de referência e a data em que foi consultada, bem como quaisquer perguntas sem resposta.
• Designe responsáveis pelas alterações à firewall, pela operação do retransmissor, pela configuração da aplicação e pelo apoio aos utilizadores.
• Volte a testar após alterações relevantes à infraestrutura ou à rede e atualize o registo.