Publicar: Diagnósticos

Esta guía explica cómo recopilar diagnósticos para editores y resolver problemas comunes.

Obtener estadísticas sobre la transmisión 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 una transmisión publicada por el cliente local, debes utilizar una sesión que emplee el Media Router (sesiones con el modo multimedia configurado en «routed») y debes configurar el 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.

Buenas prácticas a la hora de publicar

En esta sección se ofrecen consejos para publicar transmisiones 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 observado que, con diferencia, la mayoría de los casos en los que no se lleva a cabo la publicación se deben a que los usuarios hacen clic en el botón «Rechazar» o a que no hacen clic en el botón «Aceptar». Te proporcionamos todos los eventos que necesitas para poder guiar a tus usuarios a lo largo 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, ya que te conectas 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 fotogramas

Puedes configurar la resolución y la frecuencia de fotogramas del Publisher al iniciarlo:

OT.initPublisher(divId, {
  resolution: '320x240',
  frameRate: 15
});

Por defecto, la resolución de un Publisher es de 640x480, pero también puedes configurarla en 1920x1080, 1280x720 o 320x240. Lo mejor es intentar ajustar la resolución al tamaño en el que se va a mostrar el vídeo. Si solo vas a mostrar el vídeo a 320x240 píxeles, no tiene sentido transmitirlo a 1280x720 o 1920x1080. Reducir la resolución puede ahorrar ancho de banda y reducir la congestión y las caídas de 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

Sigue los consejos de esta sección para evitar problemas de conectividad al publicar. Para obtener información general sobre la resolución de problemas, consulta «Depuración — Web».

Gestión de errores

Existen métodos de devolución de llamada tanto para Session.publish() y OT.initPublisher(). Recomendamos gestionar las respuestas de error de ambos métodos. Como se ha mencionado anteriormente, lo mejor es 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() llamada de retorno.

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 evento o detectando una respuesta de error del método OT.initPublisher() con un code propiedad establecida en 1500 y un 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() El error se produce si OpenTok no puede acceder a una cámara o a un micrófono. Esto puede ocurrir si no hay ninguna cámara o micrófono conectado al equipo, si hay algún problema con el controlador de la cámara o del micrófono, o si alguna otra aplicación está utilizando la cámara o el micrófono (esto solo ocurre en Windows). Puedes intentar minimizar la aparición de estos problemas utilizando nuestro componente de configuración de hardware o llamando al 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

Las demás causas de los errores en la publicación suelen deberse a algún tipo de fallo de red. Estas situaciones se gestionan 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, te recomendamos que muestres un mensaje al usuario indicando que no se ha podido publicar y que debe comprobar su conexión a Internet. La gestión de estos errores se realiza de la siguiente manera:

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 evento con un reason propiedad establecida en «networkDisconnected» de la siguiente manera:

publisher.on({
  streamDestroyed: function (event) {
    if (event.reason === 'networkDisconnected') {
      showMessage('Your publisher lost its connection. Please check your internet connection and try publishing again.');
    }
  }
});