Melhores práticas para testes pré-chamada

Este guia descreve a experiência pré-chamada para aplicativos da Video API que desejam reduzir falhas na entrada e proteger a experiência da sessão ao vivo. Ele aborda salas de espera, permissões e configuração de dispositivos, testes de rede, interpretação de resultados e a decisão de entrada.

Um teste pré-chamada estima a qualidade da chamada em um determinado momento. Ele pode detectar problemas de configuração antes do início da sessão, mas não consegue prever o que acontecerá mais tarde durante a chamada. Continue monitorando depois que o usuário entrar na chamada com Observabilidade do cliente, eventos de qualidade e recursos de adaptação em tempo de execução.

Fluxo recomendado antes da ligação

Utilize uma sala de espera antes que o usuário entre na chamada.
Verificar as permissões da câmera e do microfone e exibir a visualização local.
Permita que o usuário escolha os dispositivos e mostre quais câmera e microfone estão selecionados no momento.
Execute o teste pré-chamada com credenciais de teste separadas e uma sessão de teste separada. Isso mantém a sessão de chamada e seus dados do Inspector separados das conexões e fluxos de teste.
Correr NetworkTest.testConnectivity() primeiro, depois NetworkTest.testQuality().
Use os resultados documentados para definir o status da sala de espera. Um modelo simples é Pass, Warn, ou Fail.
Participe da sessão após a conclusão das autorizações, da configuração do dispositivo e das verificações pré-chamada. Para Warn, uma opção é permitir que o usuário continue, acompanhado de um aviso claro.

Se você usar a biblioteca network-test, crie um arquivo separado derrotado sessão de teste. Não reutilize o ID da sessão de comunicação para a sessão de teste. Se a implementação do teste aceitar explicitamente audioSource e videoSource valores, use a câmera e o microfone selecionados na sala de espera.

Salas de espera

Uma sala de espera dá aos usuários tempo para verificar as permissões da câmera e do microfone e escolher os dispositivos antes de entrarem na chamada. Use-a para aplicar as configurações de transmissão recomendadas e realizar um teste antes da chamada, antes do início da sessão. Isso mantém a configuração separada da sessão ao vivo e ajuda a reduzir interrupções iniciais quando os participantes entram. A Aplicativo de referência na web inclui uma sala de espera para visualizar os dispositivos e realizar a configuração antes de entrar na reunião.

Interface do usuário da sala de espera

A sala de espera pode incluir o seguinte:

Pré-visualização da câmera local,
Indicador de atividade do microfone,
Seletores de câmera e microfone,
Mensagens claras sobre o status de permissão e o status de recusa,
Status do teste pré-chamada ou indicador de andamento,
Um estado visível de prontidão para a junção,
Uma ação de repetição para o teste pré-chamada.

Execute o teste novamente quando ocorrer qualquer uma das seguintes situações:

O usuário altera a câmera ou o microfone,
A rede do usuário muda,
A permissão para usar a câmera ou o microfone é concedida novamente após ter sido negada,
O usuário solicita explicitamente que se tente novamente,
Há um intervalo de tempo considerável entre a conclusão do teste e a integração.

Fluxos do apresentador e do moderador

Se o seu produto tiver uma função de anfitrião, moderador ou apresentador, mantenha os participantes na sala de espera até que o anfitrião esteja pronto para iniciar a sessão ao vivo. Para aplicativos de pequenos grupos, você pode optar por conectar os participantes à sessão antes que o anfitrião comece a apresentar. Evite uma situação em que um grande público já esteja conectado e aguardando um anfitrião que ainda não iniciou a transmissão. Quando o anfitrião inicia a transmissão, o aplicativo pode gerar um pico repentino de atividades de transmissão e assinaturas.

Se os participantes precisarem estar conectados antes do anfitrião iniciar a transmissão, planeje o fluxo de mídia de forma que o momento do início não gere todas as transmissões de uma só vez. Por exemplo, um apresentador pode publicar a mídia com o som desativado e reativá-lo quando estiver pronto, em vez de iniciar a publicação diante de um grande público que está aguardando. Avalie esse padrão em relação ao tamanho esperado do público antes de utilizá-lo em eventos de grande porte.

O Artigo sobre o aplicativo de exemplo “Sala de espera” mostra uma implementação para grupos pequenos. Para salas de espera de grande porte ou no estilo de transmissão, solicite uma análise técnica antes de implementar comportamentos personalizados para o anfitrião ou moderador.

Executar testes de rede

Utilize a biblioteca de testes da Vonage Video Network para verificar se um cliente é compatível com a transmissão de áudio e vídeo antes que os usuários entrem em uma sessão.

Se o seu aplicativo utiliza configurações configuráveis de TURN ou proxy IP, passe o correspondente iceConfig ou proxyServerUrl valores também no teste de rede.

Verificações de conectividade

Correr NetworkTest.testConnectivity() antes do teste de qualidade.

Essa verificação confirma se o cliente consegue acessar os serviços necessários para uma sessão da Video API:

API acessibilidade,
Mensagens / sinalização WebSocket acessibilidade,
Roteador de mídia acessibilidade,
Servidor de registro acessibilidade.

Interprete esses resultados com base no modo de sessão utilizado pelo seu aplicativo:

Se o api ou messaging Se a verificação falhar, o cliente não poderá estabelecer as conexões de sessão necessárias.
Se o media Se a verificação falhar, uma sessão roteada não será bem-sucedida. Uma sessão retransmitida ainda pode ser bem-sucedida, embora possa falhar se for necessário um TURN.
Se o logging Se a verificação falhar, o cliente ainda poderá se conectar, mas a Vonage não coletará os dados de registro habituais utilizados por ferramentas como o Inspector.

Controles de qualidade

Se os resultados da conectividade forem aceitáveis para o seu caso de uso, execute NetworkTest.testQuality()para testar:

Suporte de áudio,
Suporte a vídeo,
Taxa de bits de áudio e vídeo,
Índice de perda de pacotes de áudio e vídeo,
Resolução recomendada para publicação,
Taxa de quadros recomendada para publicação,
qualityLimitationReason com valores bandwidth, cpu, ou null.

Observação: O teste é executado no modo de áudio e vídeo por padrão e pode continuar no modo somente de áudio, se necessário.

Testes de tempo limite

O timeout opção para testQuality() aceita valores maiores que 5000 ms e menos que 30000 ms. Se você não definir esse valor, o teste será executado por aproximadamente:

30 segundos para um teste de áudio e vídeo,
10 segundos para um teste apenas de áudio.

Tempos de espera mais curtos reduzem a precisão dos resultados.

Compatibilidade com navegadores

testQuality() não é compatível com o Firefox. Nesse caso, use a sala de espera para as permissões e a configuração do dispositivo e recorra a testConnectivity() se você ainda quiser uma verificação pré-chamada apenas para verificar a conectividade.

Redes restritas

Em redes restritas, siga os requisitos de rede documentados:

Prefira um ambiente em que o UDP 3478 e TCP 443 estão disponíveis.
Para obter o melhor tempo de configuração e a melhor qualidade de mídia, permita também o tráfego UDP de saída 1025-65535 para os protocolos ICE e SRTP.
Se ao menos o TCP 443 Se estiver disponível, a sessão ainda poderá se conectar, mas é mais provável que a configuração seja mais lenta e a qualidade da transmissão seja inferior.
Se houver um proxy, ele deve ser transparente ou estar configurado para conexões HTTPS.

Em redes corporativas ou restritas, verifique as mesmas portas e protocolos necessários e, em seguida, execute novamente o teste de conectividade antes que o usuário entre na rede.

Para ambientes mais restritivos, consulte:

Status recomendados antes da chamada

Status	Quando usar	O que fazer a seguir
`Pass`	A conectividade é bem-sucedida para o modo de sessão utilizado pelo seu aplicativo, os meios necessários são compatíveis, a perda de pacotes está abaixo de 3%, a taxa de bits excede os limites mínimos (≥150 kbps para vídeo, ≥25 kbps para áudio) e as configurações de publicação recomendadas são aceitáveis para a chamada.	Permita que o usuário participe. Aplique a resolução de publicação e a taxa de quadros recomendadas ao inicializar o Publisher.
`Warn`	`logging` é a única verificação de conectividade com falha, a perda de pacotes é de 3 a 5%, a taxa de bits está baixa, mas é recuperável, a resolução ou taxa de quadros recomendada para publicação está reduzida, ou `qualityLimitationReason` é `bandwidth` ou `cpu`.	Mostre o motivo na sala de espera, permita que o usuário tente novamente e aplique as configurações de publicação recomendadas. Se necessário, permita que o usuário continue, acompanhado de um aviso claro.
`Fail`	`api` ou `messaging` falha, `media` ocorre uma falha no modo de sessão exigido pelo seu aplicativo, o áudio ou vídeo necessário não é compatível, as permissões ou a aquisição do dispositivo estão incompletas, a perda de pacotes excede 5% ou a taxa de bits cai abaixo dos limites críticos (<150 kbps para vídeo, <25 kbps para áudio).	Não permita que o usuário entre ainda. Mostre o problema na sala de espera e peça ao usuário para tentar novamente após corrigir o problema. Se o áudio for compatível, mas o vídeo não for, você pode oferecer a opção de participar apenas com áudio.

Quando o status é Warn ou Fail, use o sinal que o acionou para decidir o que fazer a seguir:

Se o problema for bandwidth, peça ao usuário para tentar novamente em uma rede mais potente ou menos restrita, ou continue com configurações de publicação reduzidas.
Se o problema for cpu, peça ao usuário para fechar applications que exigem muitos recursos, desativar efeitos que consomem muitos recursos e tentar novamente.
Se o problema for logging No entanto, o usuário ainda poderá se conectar, mas os dados normais do Inspector serão reduzidos.
Se o navegador for o Firefox, use a sala de espera para as permissões e a configuração do dispositivo, e use testConnectivity() se você precisar de uma verificação prévia da ligação apenas para verificar a conectividade.

Interpretação dos resultados dos testes de rede

Ao definir um status de pré-chamada, verifique:

Compatível vs. não compatível,
Resultado da conectividade,
Índice de perda de pacotes (abaixo de 3% é aceitável; entre 3% e 5% requer cautela; acima de 5% indica falha),
Níveis de taxa de bits (vídeo ≥150 kbps e áudio ≥25 kbps são os limites mínimos aceitáveis),
Resolução e taxa de quadros recomendadas para publicação,
qualityLimitationReason.

Se você precisar de diagnósticos de nível mais baixo, como tempo de ida e volta, contagem de travamentos ou estatísticas brutas do RTC, use o Client Observability ou o relatório de estatísticas brutas do WebRTC.

Indicadores de qualidade durante a chamada

Depois que o usuário se cadastrar:

Uso qualityScoreChanged para monitorar a qualidade do assinante durante a chamada 1-5 escala,
Uso cpuPerformanceChanged para responder à pressão do dispositivo em clientes web,
Utilize os eventos de qualidade de emissor e assinante do Client Observability quando precisar de mais detalhes do que as verificações básicas pré-chamada oferecem.

Para obter orientações detalhadas na web, consulte Observabilidade do cliente: Web.

Continuar após a junção

Depois que o usuário se cadastrar, continue com:

Observabilidade do cliente para métricas de fluxo contínuo,
Inscreva-se: Qualidade e Adaptação para o monitoramento da qualidade do serviço aos assinantes e o gerenciamento de reconexões,
Vídeo escalável para adaptação de fluxo multipartidário,
Alternativa de áudio para o comportamento em condições de rede prejudicada,
Sessões para alinhar sua lógica pré-chamada com o comportamento de encaminhamento versus retransmissão,
Inspetor de Sessão para validação e depuração pós-chamada.

O recurso de fallback de áudio do assinante requer uma sessão roteada. O recurso de fallback de áudio do emissor está disponível tanto em sessões roteadas quanto em sessões retransmitidas.