Prácticas recomendadas para las pruebas previas a la llamada

Esta guía describe una experiencia previa a la llamada para aplicaciones de Video API que desean reducir los fallos de conexión y proteger la experiencia de la sesión en directo. Abarca las salas de espera, la configuración de permisos y dispositivos, las pruebas de red, la interpretación de resultados y la decisión de unirse.

Una prueba previa a la llamada calcula la calidad de la llamada en un momento dado. Puede detectar problemas de configuración antes de que empiece la sesión, pero no puede predecir lo que ocurrirá más adelante en la llamada. Sigue vigilando después de que el usuario se incorpore con Observabilidad del clientey funciones de adaptación en tiempo de ejecución.

Flujo recomendado previo a la llamada

  1. Utilizar una sala de espera antes de que el usuario se incorpore a la llamada.
  2. Comprueba los permisos de la cámara y el micrófono y muestra la vista previa local.
  3. Permitir al usuario elegir dispositivos y mostrar qué cámara y micrófono están seleccionados actualmente.
  4. Ejecute la prueba previa a la llamada con credenciales de prueba independientes y una sesión de prueba separada. Esto mantiene la sesión de llamada y sus datos del Inspector separados de las conexiones y flujos de prueba.
  5. Ejecutar NetworkTest.testConnectivity() primero, y luego NetworkTest.testQuality().
  6. Utilice las salidas documentadas para establecer un estado de sala de espera. Un modelo sencillo es Pass, Warno Fail.
  7. Únase a la sesión una vez completados los permisos, la configuración del dispositivo y las comprobaciones previas a la llamada. Para Warnuna opción es dejar que el usuario continúe con una advertencia clara.

Si utiliza la biblioteca network-test, cree un archivo enrutado sesión de prueba. No reutilice el identificador de sesión de comunicación para la sesión de prueba. Si la implementación de la prueba acepta explícitamente audioSource y videoSource valores, utilice la cámara y el micrófono seleccionados en la sala de espera.

Salas de espera

Una sala de espera da tiempo a los usuarios para comprobar los permisos de cámara y micrófono y elegir los dispositivos antes de entrar en la llamada. Utilícela para aplicar los ajustes de publicación recomendados y realizar una prueba previa a la llamada antes de que comience la sesión. Esto mantiene la configuración separada de la sesión en directo y ayuda a reducir las interrupciones tempranas cuando se incorporan los participantes. En Aplicación web de referencia incluye una sala de espera para ver los dispositivos y ocuparse de la configuración antes de unirse.

Sala de espera

La sala de espera puede incluir lo siguiente:

  • Vista previa de la cámara local,
  • Indicador de actividad del micrófono,
  • Selectores de cámara y micrófono,
  • Borrar estado de permiso y mensajes de estado denegado,
  • Indicador de estado o progreso de la prueba previa a la llamada,
  • Un estado de preparación de la unión visible,
  • Una acción de reintento para la prueba previa a la llamada.

Vuelva a ejecutar la prueba cuando se produzca cualquiera de los siguientes casos:

  • El usuario cambia la cámara o el micrófono,
  • La red del usuario cambia,
  • Se vuelve a conceder el permiso de cámara o micrófono después de haber sido denegado,
  • El usuario pide explícitamente volver a intentarlo,
  • Transcurre un tiempo considerable entre la finalización de la prueba y la unión.

Patrones de anfitrión o moderador

Si su producto tiene una función de anfitrión, moderador o presentador, los participantes pueden permanecer en la sala de espera hasta que el anfitrión esté listo para iniciar la sesión en directo. En algunas aplicaciones moderadas o de grupos pequeños, los participantes pueden unirse a la sesión antes de que el anfitrión publique y permanecer conectados pero sin publicar hasta que el anfitrión esté listo. Trate este enfoque de conexión pero sin publicación como un patrón opcional a nivel de aplicación con compensaciones de escala, no como una recomendación general o un requisito de la plataforma Video API. Para audiencias más grandes, conectar previamente a muchos participantes puede crear una ráfaga de suscripciones cuando el anfitrión comience a publicar. El sitio sala de espera ejemplo de aplicación artículo muestra un ejemplo de aplicación.

Ejecutar pruebas de red

Utiliza la biblioteca de prueba de la red de video de Vonage para verificar si un cliente puede admitir la publicación de audio y video antes de que los usuarios se unan a una sesión.

Si su aplicación utiliza parámetros configurables de TURN o de proxy IP, pase el correspondiente iceConfig o proxyServerUrl en la prueba de red.

Comprobaciones de conectividad

Ejecutar NetworkTest.testConnectivity() antes de la prueba de calidad.

Esta comprobación verifica si el cliente puede acceder a los servicios necesarios para una sesión de Video API:

  • API alcanzabilidad,
  • Mensajería / señalización WebSocket alcanzabilidad,
  • Enrutador multimedia alcanzabilidad,
  • Servidor de registro alcanzabilidad.

Interprete estos resultados en función del modo de sesión que utilice su aplicación:

  • Si el api o messaging falla, el cliente no puede establecer las conexiones de sesión necesarias.
  • Si el media falla, una sesión enrutada no tendrá éxito. Una sesión retransmitida puede tener éxito, aunque también puede fallar si se necesita TURN.
  • Si el logging el cliente podrá seguir conectándose, pero Vonage no recopilará los datos de registro habituales que utilizan herramientas como Inspector.

Controles de calidad

Si los resultados de conectividad son aceptables para su caso de uso, ejecute NetworkTest.testQuality()para probar:

  • Soporte de audio,
  • Soporte de vídeo,
  • Velocidad de bits de audio y vídeo,
  • Ratio de pérdida de paquetes de audio y vídeo,
  • Resolución de publicación recomendada,
  • Frecuencia de imagen recomendada para la publicación,
  • qualityLimitationReason con valores bandwidth, cpuo null.

Nota: La prueba se ejecuta en modo audio-vídeo por defecto y puede continuar en modo sólo audio si es necesario.

Pruebas de tiempo de espera

En timeout opción para testQuality() acepta valores superiores a 5000 ms y menos de 30000 ms. Si no lo ajusta, la prueba se ejecuta durante aproximadamente:

  • 30 segundos para una prueba audio-vídeo,
  • 10 segundos para una prueba sólo de audio.

Los tiempos de espera inferiores reducen la precisión de los resultados.

Compatibilidad con navegadores

testQuality() no es compatible con Firefox. En ese caso, utilice la sala de espera para los permisos y la configuración del dispositivo, y confíe en testConnectivity() si aún desea una comprobación previa a la llamada sólo de conectividad.

Redes restringidas

En redes restringidas, siga los requisitos de red documentados:

  • Prefiera un entorno en el que UDP 3478 y TCP 443 están disponibles.
  • Para obtener el mejor tiempo de configuración y calidad de los medios, permita también la salida UDP 1025-65535 para medios ICE y SRTP.
  • Si sólo TCP 443 la sesión puede seguir conectándose, pero es más probable que la configuración sea más lenta y la calidad de los medios más baja.
  • Si hay un proxy, debe ser transparente o estar configurado para conexiones HTTPS.

En redes corporativas o restringidas, verifique los mismos puertos y protocolos requeridos, luego vuelva a ejecutar la prueba de conectividad antes de que el usuario se una.

Para entornos más restrictivos, véase:

Estados recomendados previos a la llamada

Estado Utilícelo cuando Qué hacer a continuación
Pass La conectividad es satisfactoria para el modo de sesión que utiliza su aplicación, se admiten los medios necesarios, la pérdida de paquetes es inferior al 3%, la velocidad de bits supera los umbrales mínimos (≥150 kbps de vídeo, ≥25 kbps de audio) y los ajustes de publicación recomendados son aceptables para la llamada. Deje que el usuario se una. Aplique la resolución de publicación y la velocidad de fotogramas recomendadas al inicializar el Editor.
Warn logging es la única comprobación de conectividad que falla, la pérdida de paquetes es del 3-5%, la tasa de bits es baja pero recuperable, la resolución de publicación recomendada o la tasa de fotogramas es reducida o qualityLimitationReason es bandwidth o cpu. Muestre el motivo en la sala de espera, deje que el usuario vuelva a intentarlo y aplique los ajustes de publicación recomendados. Si es necesario, permita que el usuario continúe con una advertencia clara.
Fail api o messaging falla, media falla para el modo de sesión que requiere su aplicación, el audio o vídeo requerido no es compatible, la adquisición de permisos o dispositivos está incompleta, la pérdida de paquetes supera el 5% o la tasa de bits cae por debajo de umbrales críticos (<150 kbps de vídeo, <25 kbps de audio). No permita que el usuario se una todavía. Muestre el problema en la sala de espera y pida al usuario que vuelva a intentarlo después de solucionarlo. Si se admite audio, pero no vídeo, puede ofrecer la posibilidad de unirse solo con audio.

Cuando el estado es Warn o FailUtiliza la señal que lo ha provocado para decidir qué hacer a continuación:

  • Si se trata de bandwidthSi el usuario no puede acceder a la red, pídale que vuelva a intentarlo en una red más potente o menos restringida, o que continúe con una configuración de publicación reducida.
  • Si se trata de cpu, pida al usuario que cierre las aplicaciones exigentes, desactive los efectos caros y vuelva a intentarlo.
  • Si se trata de logging solamente, el usuario podrá seguir conectándose, pero se reducirán los datos normales del Inspector.
  • Si el navegador es Firefox, utilice la sala de espera para los permisos y la configuración del dispositivo, y utilice testConnectivity() si necesita una comprobación previa a la llamada sólo de conectividad.

Interpretación de los resultados de las pruebas de red

Al establecer un estado previo a la llamada, compruebe:

  • Apoyado vs. no apoyado,
  • Resultado de la conectividad,
  • Ratio de pérdida de paquetes (por debajo del 3% es aceptable; entre el 3 y el 5% requiere precaución; por encima del 5% indica fallo),
  • Niveles de bitrate (vídeo ≥150 kbps y audio ≥25 kbps son umbrales mínimos aceptables),
  • Resolución de publicación y frecuencia de imagen recomendadas,
  • qualityLimitationReason.

Si necesita diagnósticos de nivel inferior, como tiempo de ida y vuelta, recuentos de congelaciones o estadísticas RTC sin procesar, utilice Client Observability o el informe de estadísticas WebRTC sin procesar.

Señales de calidad In-Call

Después de que el usuario se una:

  • Utilice qualityScoreChanged seguimiento de la calidad del abonado en el entero de llamada 1-5 escala,
  • Utilice cpuPerformanceChanged para reaccionar a la presión del dispositivo en los clientes web,
  • Utilice los eventos de calidad de editor y suscriptor de Client Observability cuando necesite más detalles de los que ofrecen las comprobaciones básicas previas a la llamada.

Para obtener información detallada, consulte Observabilidad del cliente: Web.

Continuar después de unirse

Después de que el usuario se una, continúe con:

El audio fallback de abonado requiere una sesión enrutada. El audio fallback del editor está disponible tanto en sesiones enrutadas como retransmitidas.