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.

Padrões de apresentador ou moderador

Se o seu produto tiver uma função de anfitrião, moderador ou apresentador, os participantes podem permanecer na sala de espera até que o anfitrião esteja pronto para iniciar a sessão ao vivo. Em algumas aplicações para grupos pequenos ou moderadas, os participantes podem, em vez disso, ingressar na sessão antes que o anfitrião inicie a transmissão e permanecer conectados, mas sem transmitir, até que o anfitrião esteja pronto. Considere essa abordagem de “conectado, mas sem transmissão” como um padrão opcional no nível da aplicação, com compromissos em termos de escalabilidade, e não como uma recomendação geral ou um requisito da Video API. Para públicos maiores, a pré-conexão de muitos participantes pode gerar um pico de assinaturas quando o anfitrião começar a transmitir. O Artigo sobre o aplicativo de exemplo “Sala de espera” mostra um exemplo de implementação.

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.