Buenas prácticas para las pruebas previas a las llamadas

Esta guía describe el proceso previo a la llamada para aplicaciones de la Video API que deseen reducir los errores al unirse a una sesión y garantizar una buena experiencia durante la sesión en directo. Abarca las salas de espera, los permisos y la configuración de los dispositivos, las pruebas de red, la interpretación de los resultados y la decisión de unirse a la sesión.

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 examen independientes y una sesión de prueba independiente. De este modo, la sesión de llamada y los datos de su Inspector permanecen separados de las conexiones y los flujos de prueba.
  5. Correr 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, Warn, o 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 utilizas la biblioteca network-test, crea un archivo derrotado Sesión de prueba. No reutilices 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 permite a los usuarios comprobar los permisos de la cámara y el micrófono y seleccionar los dispositivos antes de incorporarse a la llamada. Úsala para aplicar la configuración de publicación recomendada y realizar una prueba previa a la llamada antes de que comience la sesión. De este modo, la configuración se mantiene separada de la sesión en directo y se reducen las interrupciones iniciales cuando los participantes se incorporan. La Aplicación web de referencia Incluye una sala de espera para probar los dispositivos y realizar la configuración antes de incorporarse.

Sala de espera

La sala de espera puede contar con lo siguiente:

  • Vista previa de la cámara local,
  • Indicador de actividad del micrófono,
  • Selectores de cámara y micrófono,
  • Mensajes claros sobre el estado de los permisos y el estado de denegación,
  • 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 incorporación.

Patrones de presentador 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 valores en la prueba de red también.

Comprobaciones de conectividad

Correr 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 la Video API:

  • API accesibilidad,
  • Mensajería / señalización WebSocket accesibilidad,
  • Enrutador multimedia accesibilidad,
  • 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 Si la comprobación falla, el cliente no puede establecer las conexiones de sesión necesarias.
  • Si el media Si la comprobación falla, una sesión enrutada no se llevará a cabo con éxito. Una sesión retransmitida podría llevarse a cabo con éxito, aunque también podría fallar si se requiere TURN.
  • Si el logging Si la comprobación falla, es posible que el cliente pueda conectarse de todos modos, 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,
  • Compatibilidad con vídeo,
  • Velocidad de bits de audio y vídeo,
  • Índice de pérdida de paquetes de audio y vídeo,
  • Resolución de publicación recomendada,
  • Frecuencia de fotogramas recomendada para la publicación,
  • qualityLimitationReason con valores bandwidth, cpu, o null.

Nota: La prueba se ejecuta en modo de audio y vídeo de forma predeterminada y puede continuar en modo de solo audio si es necesario.

Pruebas de tiempo de espera

El 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 solo de audio.

Un tiempo de espera más corto reduce la precisión de los resultados.

Compatibilidad con navegadores

testQuality() no es compatible con Firefox. En ese caso, utiliza la sala de espera para gestionar los permisos y configurar el dispositivo, y recurre a testConnectivity() si aún desea una comprobación previa a la llamada sólo de conectividad.

Redes restringidas

En redes con restricciones, sigue los requisitos de red documentados:

  • Prefiero un entorno en el que UDP 3478 y TCP 443 están disponibles.
  • Para obtener un tiempo de configuración óptimo y la mejor calidad de transmisión, permite también el tráfico UDP saliente. 1025-65535 para los protocolos ICE y SRTP.
  • Ojalá fuera 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 servidor 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 correcta para el modo de sesión que utiliza tu 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 para vídeo, ≥25 kbps para audio) y la configuración de publicación recomendada es adecuada 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 se produce un error en el modo de sesión que requiere tu aplicación, el audio o el vídeo necesarios no son compatibles, los permisos o la adquisición del dispositivo están incompletos, la pérdida de paquetes supera el 5 % o la tasa de bits cae por debajo de los umbrales críticos (<150 kbps para el vídeo, <25 kbps para el audio). No permitas que el usuario se una todavía. Muestra el problema en la sala de espera y pídele que lo vuelva a intentar una vez que lo haya solucionado. Si el audio funciona pero el vídeo no, puedes ofrecerle la opción 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 bandwidth, pide al usuario que lo intente de nuevo en una red con mayor cobertura o menos restricciones, o que continúe con una configuración de publicación reducida.
  • Si se trata de cpu, pide al usuario que cierre las aplicaciones que consumen muchos recursos, desactive los efectos que consumen muchos recursos y vuelva a intentarlo.
  • Si se trata de logging Sin embargo, el usuario podrá seguir conectándose, aunque se reducirá la cantidad de datos normales del Inspector.
  • Si el navegador es Firefox, utiliza la sala de espera para gestionar los permisos y configurar el dispositivo, y utiliza 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, comprueba lo siguiente:

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

Si necesitas datos de diagnóstico de nivel más bajo, como el tiempo de ida y vuelta, el recuento de bloqueos o las estadísticas sin procesar de RTC, utiliza Client Observability o el informe de estadísticas sin procesar de WebRTC.

Señales de calidad In-Call

Después de que el usuario se una:

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

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

Continuar tras la unión

Una vez que el usuario se haya registrado, continúa con:

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