Publicar: Diagnóstico
Esta guía explica cómo recopilar diagnósticos para editores y resolver problemas comunes.
Obtener estadísticas sobre el flujo de un editor
El SDK de video de Vonage expone métricas detalladas de la calidad de la transmisión a través de una API de estadísticas de alto nivel, recomendada para la mayoría de los casos de uso, que proporciona estadísticas de audio, video, red y del lado del emisor en una forma unificada y consciente de la sesión que permanece estable a través de las transiciones de conexión entre pares. Para la depuración avanzada, el SDK también ofrece acceso al informe de estadísticas WebRTC sin procesar, que refleja los datos de la conexión entre pares sin procesar.
Consulte guía del desarrollador de la observabilidad del cliente para obtener información detallada.
Corriente de prueba
Puedes publicar un flujo de prueba y comprobar sus estadísticas de audio y vídeo para determinar el tipo de flujo (como alta resolución o sólo audio) que admite tu conexión.
Para obtener estadísticas de un flujo publicado por el cliente local, debe utilizar una sesión que utilice el enrutador de medios (sesiones con el modo de medios establecido en enrutado), y debe establecer el parámetro testNetwork propiedad a true en el options que se pasa al objeto Session.subscribe() método. A continuación, puede utilizar el método getStats() del objeto Subscriber para obtener las estadísticas de audio y vídeo del flujo que publique.
Puede utilizar la función SubscriberKit.setAudioStatsListener(AudioStatsListener listener) y SubscriberKit.setVideoStatsListener(VideoStatsListener listener) del objeto Subscriber para obtener estadísticas de audio y vídeo del flujo que publique.
Véase este tema para más información.
Puede utilizar la función networkStatsDelegate del objeto OTSubscriberKit para obtener las estadísticas de audio y vídeo del flujo que publiques.
En vonage-video-api-network-test-samples repo incluye código de ejemplo para mostrar cómo utilizar las estadísticas de un flujo de prueba antes de publicarlo en una sesión.
Puede utilizar la función networkStatsDelegate del objeto OTSubscriberKit para obtener las estadísticas de audio y vídeo del flujo que publiques.
En vonage-video-api-network-test-samples repo incluye código de ejemplo para mostrar cómo utilizar las estadísticas de un flujo de prueba antes de publicarlo en una sesión.
A continuación, puede suscribirse al flujo y utilizar la función Subscriber.AudioStatsUpdated y Subscriber.VideoStatsUpdated para obtener estadísticas de audio y vídeo del flujo que publiques.
Buenas prácticas de publicación
Esta sección incluye consejos para publicar flujos con éxito.
Permitir el acceso de dispositivos
Es una buena práctica informar a los usuarios de que se les va a pedir que permitan el acceso a su cámara y micrófono.
Hemos comprobado que el mayor número de fallos en la publicación se debe a que los usuarios hacen clic en el botón "denegar" o no hacen clic en el botón "permitir". Te proporcionamos todos los eventos que necesitas para poder guiar a tus usuarios a través de este proceso:
publisher.on({
accessDialogOpened: function (event) {
// Show allow camera message
pleaseAllowCamera.style.display = 'block';
},
accessDialogClosed: function (event) {
// Hide allow camera message
pleaseAllowCamera.style.display = 'none';
}
});
También es una buena idea servir su sitio web a través de SSL. Esto se debe a que Chrome sólo requiere que los usuarios hagan clic para permitir el acceso a los dispositivos una vez por dominio si ese dominio se sirve a través de SSL. Esto significa que sus usuarios (si están en Chrome) no tienen que lidiar con ese incómodo cuadro de diálogo de permitir/denegar cada vez que cargan la página.
Dividir OT.initPublisher() y Session.publish()
Otra cosa que recomendamos es dividir el OT.initPublisher() y Session.publish() pasos. Esto acelera el tiempo de conexión inicial porque te estás conectando a la sesión mientras esperas a que el usuario haga clic en el botón permitir. Así que en lugar de:
session.connect(token, function (err) {
{... your error handling code ...}
if (!err) {
var publisher = OT.initPublisher();
session.publish(publisher);
}
});
Mueva el OT.initPublisher() paso a antes de conectarse, como en el siguiente:
var publisher = OT.initPublisher();
session.connect(token, function (err) {
{... your error handling code ...}
if (!err) {
session.publish(publisher);
}
});
Resolución y frecuencia de imagen
Puedes configurar la resolución y la velocidad de fotogramas del Editor al inicializarlo:
OT.initPublisher(divId, {
resolution: '320x240',
frameRate: 15
});
Por defecto, la resolución de un editor es de 640x480, pero también puedes establecerla en 1920x1080, 1280x720 o 320x240. Lo mejor es intentar ajustar la resolución al tamaño en que se mostrará el vídeo. Si sólo vas a visualizar el vídeo a 320x240 píxeles, no tiene sentido transmitir a 1280x720 o 1920x1080. Reducir la resolución puede ahorrar ancho de banda y reducir la congestión y las caídas de la conexión.
Por defecto, la velocidad de fotogramas del vídeo es de 30 fotogramas por segundo, pero también puedes establecerla en 15, 7 o 1. Reducir la frecuencia de imagen puede reducir el ancho de banda necesario. Los vídeos de menor resolución pueden tener una frecuencia de imagen más baja sin que el usuario perciba tanta diferencia. Por lo tanto, si utilizas una resolución baja, también deberías pensar en utilizar una frecuencia de imagen baja.
Solución de problemas
Siga los consejos de esta sección para evitar problemas de conectividad al publicar. Para obtener información general sobre la solución de problemas, consulte Depuración - Web.
Tratamiento de errores
Existen métodos de devolución de llamada tanto para Session.publish() y OT.initPublisher(). Recomendamos manejar las respuestas de error a ambos métodos. Como se mencionó anteriormente, es mejor dividir estos pasos y llamar a OT.initPublisher() antes de que haya comenzado a conectarse a su Sesión. También facilita el manejo de errores si no está llamando a ambos métodos al mismo tiempo. Esto se debe a que ambos manejadores de error se dispararán si hay algún error publicando. Es mejor esperar a que OT.initPublisher() para completar y Session.connect() para completar y luego llamar a Session.publish(). De este modo, podrá gestionar todos los problemas relacionados con el hardware en el OT.initPublisher() y todas las cuestiones relacionadas con la red en el Session.publish() devolución de llamada.
var connected = false,
publisherInitialized = false;
var publisher = OT.initPublisher(function(err) {
if (err) {
// handle error
} else {
publisherInitialized = true;
publish();
}
});
var publish = function() {
if (connected && publisherInitialized) {
session.publish(publisher);
}
};
session.connect(token, function(err) {
if (err) {
// handle error
} else {
connected = true;
publish();
}
});
Acceso denegado
El mayor número de fallos de OT.initPublisher() se deben a que el usuario final deniega el acceso a la cámara y al micrófono. Esto puede solucionarse escuchando el accessDenied o esperando una respuesta de error al método OT.initPublisher() con un valor de code a 1500 y una propiedad message con el valor "Acceso al editor denegado:". Le recomendamos que gestione este caso y emita un mensaje al usuario indicándole que debe intentar publicar de nuevo y permitir el acceso a la cámara.
publisher.on({
'accessDenied': function() {
showMessage('Please allow access to the Camera and Microphone and try publishing again.');
}
});
Acceso a dispositivos
Otra razón para OT.initPublisher() para fallar es si OpenTok no puede acceder a una cámara o micrófono. Esto puede ocurrir si no hay cámara o micrófono conectado a la máquina, si hay algún problema con el controlador de la cámara o el micrófono, o si alguna otra aplicación está utilizando la cámara o el micrófono (esto sólo ocurre en Windows). Puede intentar minimizar la aparición de estos problemas utilizando nuestro Componente de configuración de hardware o llamando a la función OT.getDevices() directamente. Sin embargo, también debe manejar cualquier error al llamar a OT.initPublisher() porque algo podría salir mal. Por ejemplo, el usuario podría haber denegado el acceso a la cámara o al micrófono. En este caso, el error.name se establece en "OT_USER_MEDIA_ACCESS_DENIED":
publisher = OT.initPublisher('publisher', {}, function (err) {
if (err) {
if (err.name === 'OT_USER_MEDIA_ACCESS_DENIED') {
// Access denied can also be handled by the accessDenied event
showMessage('Please allow access to the Camera and Microphone and try publishing again.');
} else {
showMessage('Failed to get access to your camera or microphone. Please check that your webcam'
+ ' is connected and not being used by another application and try again.');
}
publisher.destroy();
publisher = null;
}
});
Errores de red
Los otros motivos de fallos en la publicación suelen deberse a algún tipo de fallo de la red. Nos ocupamos de ellos en la llamada de retorno a Session.publish(). Si el usuario no está conectado a la red, a la función de devolución de llamada se le pasa un objeto de error con el valor name con el valor "OT_NOT_CONNECTED". Si el usuario se encuentra en una conexión de red realmente restrictiva que no permite conexiones WebRTC, el Editor no podrá conectarse y el elemento Editor mostrará una rueda giratoria. Este error tiene un name con el valor "OT_CREATE_PEER_CONNECTION_FAILED". En este caso, le recomendamos que envíe un mensaje al usuario indicándole que no ha podido publicar y que compruebe su conexión de red. El tratamiento de estos errores es el siguiente:
session.publish(publisher, function(err) {
if (err) {
switch (err.name) {
case "OT_NOT_CONNECTED":
showMessage("Publishing your video failed. You are not connected to the internet.");
break;
case "OT_CREATE_PEER_CONNECTION_FAILED":
showMessage("Publishing your video failed. This could be due to a restrictive firewall.");
break;
default:
showMessage("An unknown error occurred while trying to publish your video. Please try again later.");
}
publisher.destroy();
publisher = null;
}
});
Perder conectividad
Su Editor también puede perder su conexión después de haber logrado conectarse. En la mayoría de los casos, esto también provocará que la sesión pierda su conexión, pero no siempre es así. Puede manejar la desconexión del Publisher escuchando el comando streamDestroyed con un reason con el valor "networkDisconnected":
publisher.on({
streamDestroyed: function (event) {
if (event.reason === 'networkDisconnected') {
showMessage('Your publisher lost its connection. Please check your internet connection and try publishing again.');
}
}
});