Reservas¶

Importante

Versión beta 2.1. Lo que se describe aquí solo existe en la versión beta 2.1: se instala desde el repositorio beta y solo con una licencia; la versión estable 2.0.2 y la versión de demostración no lo incluyen. La versión beta se suministra sin garantías y el soporte se presta en la medida de lo posible (Programa de pruebas beta).

La reserva Meshwork es una reserva en caliente de salidas multicast entre los nodos de un mismo dominio. Varios nodos reciben un mismo origen y mantienen salidas idénticas hacia una misma dirección multicast y un mismo puerto; al aire envía a esa dirección solo uno de ellos, el emisor elegido. Si el emisor falla o se detiene, otro nodo asume el grupo, y los receptores siguen recibiendo el flujo desde la misma dirección sin interrupción y sin repeticiones.

Además de los grupos multicast, la reserva Meshwork forma grupos OTT: la entrega OTT de un mismo canal en distintos nodos (Grupos OTT).

El estado y los ajustes de la reserva de este nodo están reunidos en la pantalla «Reservas» del área Meshwork (Meshwork). La versión de demostración no tiene reserva: el elemento de menú no está disponible.

Grupos de reserva¶

Un grupo lo forman las salidas de los nodos del dominio que envían a una misma dirección multicast y un mismo puerto y que tienen activado el campo «Reserva Meshwork» (bloque «Reserva Meshwork» del editor de la salida). Pueden ser miembros las salidas UDP, RTP y Pro-MPEG (UDP, RTP, Pro-MPEG y TCP). Las salidas MPTS se muestran en el grupo, pero no se reservan.

Qué necesita un grupo:

la reserva está activada en cada nodo con un miembro — campo «Reserva Meshwork» de la pestaña «Ajustes» de la pantalla «Reservas», y después un reinicio del servicio;
los nodos tienen definidos el nombre del nodo y el dominio (Configuración del servidor), y todos están en un mismo dominio principal: con nodos de otro dominio no se forma reserva;
el puerto UDP del canal de control (43975 por defecto) está abierto entre los nodos del dominio;
la salida tiene una dirección multicast y una interfaz de envío, «Multicast egress interface»;
los flujos de los miembros tienen el mismo «Tipo de flujo» y la misma marca de canal cifrado: con ellos los nodos comparan los orígenes.

El canal de control de la reserva está protegido con la clave del dominio Meshwork, por lo que debe ser la misma en todos los miembros. Los nodos con claves distintas no se aceptan entre sí: en la tabla de nodos se ve como «Fallo de autenticación» y «No coincide» en la columna «Clave».

Un mismo origen o no. Los nodos comparan continuamente los flujos de sus miembros por las marcas de tiempo y el contenido. El resultado se muestra en la columna «Origen»: «Mismo origen», «Misma señal» (las mismas marcas de tiempo, otra codificación), «Por etiqueta», «Marcas de tiempo propias», «No probado», «El descifrado difiere» o «Pendiente» mientras hay pocos datos. Si la entrada del flujo pone ella misma las marcas de tiempo (archivo, RTMP, RTSP, transcodificador, multiplexor MPTS), no se pueden comparar: configure el mismo campo «Etiqueta de origen de reserva» en el editor del flujo en todos los miembros.

Quién envía¶

En el modo predeterminado — campo «Solo emite el emisor elegido (reserve-gate)» de la pestaña «Ajustes», activado — en cada grupo solo envía el nodo elegido, y los demás miembros mantienen el flujo listo. Si se desactiva este campo, la reserva funciona en modo de observación: los miembros se comprueban y se muestran, pero envían todos. El campo se lee al arrancar el servicio; configúrelo igual en todos los nodos del dominio.

El emisor lo eligen por votación los nodos del dominio con la reserva activada. Tras arrancar, un nodo pasa primero una cuarentena: no vota ni compite hasta que oye a los votantes (no más de 15 segundos). Un grupo pasa por sí solo a otro miembro cuando:

el nodo del emisor o su canal de control deja de responder;
la salida del emisor deja de enviar;
la entrada del emisor ha enmudecido o ha pasado a una de respaldo, y otro miembro tiene un flujo mejor.

Si el origen desaparece en todos los miembros a la vez, el grupo no conmuta. Un nodo que se detiene de forma normal cede primero sus grupos. Tras conmutaciones frecuentes, la conmutación automática del grupo se suspende: el grupo queda «congelado» (alerta de código 72, reserve-frozen, Reserva de flujos).

El emisor también se puede elegir a mano: botón «Mover a…» en la fila del grupo. El emisor actual y el nuevo conmutan en un mismo instante de la escala de tiempo del grupo, sin interrupción y sin repetición; la salida del nuevo miembro debe estar abierta y enviando. El campo «Prioridad de reserva» de la salida (0–9, primero el mayor) define el miembro preferido, y «Devolver tras (s)», tras cuántos segundos de estar listo ese miembro el grupo vuelve a él (0 — nunca: el grupo se queda hasta que lo muevan).

Dominio de dos nodos. Cuando solo votan dos nodos, un nodo reiniciado toma un grupo del otro no antes de 30 segundos después de su arranque, y solo si el otro nodo ha desaparecido de verdad de Meshwork. Un tercer nodo con la reserva activada también vota y elimina esta espera; no es necesario que tenga miembros.

Cada conmutación se registra en el registro de eventos del flujo y se ve en la pista «Reserva» de los gráficos de estadísticas (La pista «Reserva»).

Retardo de salida¶

Para que la conmutación sea transparente, las salidas de reserva envían el flujo con un retardo fijo respecto a la entrada: es la escala de tiempo del grupo. La define el campo «Retardo de salida (ms)» de la pestaña «Ajustes»: de 500 a 2500, 500 por defecto. Configure el mismo valor en todos los miembros del grupo.

Un valor nuevo se aplica a una salida cuando se vuelve a abrir: al arrancar o tras una pausa de la salida de unos segundos y su reanudación. Una salida en marcha sigue con el retardo anterior, y la pantalla «Reservas» muestra qué valor se aplicará. Si un miembro de reserva va por detrás del emisor, el emisor desplaza él mismo la escala de tiempo del grupo más tarde: no más de 300 ms por encima del retardo definido y no más allá de 2500 ms; cuando el retraso desaparece, el retardo vuelve en pasos de 5 ms cada 5 segundos.

Segunda ruta y Pro-MPEG¶

Un miembro con una salida RTP o Pro-MPEG también puede enviar una segunda ruta según SMPTE ST 2022-7 (Requisitos de red para ST 2022-7). El emisor del grupo envía ambas rutas. Configure la segunda ruta igual en todos los miembros, incluida «Path 2 multicast egress interface»: los nodos vigilan al emisor también por la segunda ruta. Si la segunda ruta de un miembro difiere, el grupo muestra el problema «La ruta 2 difiere entre miembros»: cambiar a ese miembro moverá o quitará la segunda ruta en los receptores.

Si la entrada del flujo recibe ella misma dos rutas, el retardo de salida debe ser al menos la ventana de espera de la segunda ruta («Path skew (ms)» de la entrada) más 400 ms. De lo contrario, la conmutación ante una pérdida real de la entrada no será transparente, y el grupo muestra el problema «Retardo de reserva menor que la espera de fusión».

Una salida Pro-MPEG participa en la selección del emisor solo con una matriz FEC determinada y sin multiplexado ni frase de contraseña (salida Pro-MPEG en un grupo de reserva).

Grupos OTT¶

Un grupo OTT reúne la entrega OTT (HLS, LL-HLS, DASH) de un mismo canal en distintos nodos del dominio: flujos o conjuntos adaptativos con el mismo nombre de grupo. Los miembros se encuentran y se comprueban entre sí, y un espectador HLS cuyo nodo ha fallado sigue viendo desde otro miembro sin salir del reproductor (Paso de los espectadores a otro nodo).

Cómo activarlo. La reserva Meshwork debe estar activada en el nodo (Grupos de reserva). Después, en un flujo (pestaña «Flujo» del editor, bloque «Reserva Meshwork») o en la ventana de un conjunto adaptativo, active el campo «Reserva OTT» e indique «Nombre del grupo de reserva»:

hasta 64 caracteres A-Z a-z 0-9 _ . -, distingue mayúsculas de minúsculas; el mismo nombre en todos los nodos por los que pasa el canal;
con el campo vacío, el nombre del grupo es el nombre OTT: «Nombre del flujo en la URL» en un flujo, «Nombre OTT» en un conjunto. Sin ninguno de los dos nombres, el miembro no se anuncia a los demás nodos;
un cambio se aplica en menos de un segundo y no reinicia la entrega OTT del flujo.

Solo puede ser miembro un flujo SPTS con la entrega OTT activada; en un flujo MPTS el campo no tiene efecto. Un conjunto adaptativo es un solo miembro, y sus escalones son los flujos del conjunto con vídeo. Las fuentes de los flujos se comparan igual que en los grupos multicast, por lo que «Tipo de flujo» y «Canal codificado» deben coincidir entre los miembros; los conjuntos adaptativos se emparejan por nombre. Para que los demás nodos accedan al servidor OTT de este nodo por nombre, indique el «Nombre de host» del servidor HTTP (Servidor HTTP de streaming): sin él, los demás nodos reciben la dirección del nodo, y solo por HTTP si el certificado del nodo no está emitido para esa dirección.

La tarjeta del grupo OTT en la pestaña «Estado» muestra el nombre del grupo, los formatos que sirve («Sirve: …»), el estado, el resultado de la comparación de la fuente y los problemas. Estados:

«Respaldado»: un miembro en otro nodo puede sustituir a este;
«Sin protección»: otros nodos tienen miembros, pero ninguno puede sustituir a este;
«Clave pendiente»: el nodo aún no tiene una clave de dominio acordada;
«No es miembro»: la reserva OTT está activada, pero el flujo o el conjunto no participa: no hay nombre de grupo, el nombre no es válido, es un flujo MPTS o aún no hay dominio; el motivo está en los problemas;
«Nombre duplicado»: dos flujos o conjuntos de este nodo tienen el mismo nombre de grupo, y ninguno de ellos se anuncia.

Para cada miembro la tarjeta muestra: «Respaldo», que es «Puede respaldar» o «No se ofrece» con la primera comprobación no superada; «Paso del espectador», es decir, cómo pasaría un espectador a este miembro («Alineado», «Misma línea de tiempo» o «Desde cero»); «En vivo» y «Archivo». Un miembro en un nodo con una versión anterior a la 2.1.0.456 no acepta espectadores: si las demás comprobaciones se superan, la columna «Respaldo» indica «Su versión aún no puede asumir espectadores». Si todos los miembros de los demás nodos están en ese caso, el grupo queda sin protección.

Problemas de un grupo OTT:

Problema	Qué significa
«Sin nombre de grupo»	Ni «Nombre del grupo de reserva» ni nombre OTT: el miembro no se anuncia.
«Nombre de reserva no válido»	Un nombre con caracteres no permitidos o de más de 64 caracteres, leído del archivo de ajustes. Mientras no se corrija, el flujo no es miembro; el nombre OTT no lo sustituye.
«Sin respaldo en otro nodo»	Durante 60 segundos ningún miembro de otro nodo puede sustituir a este: en los demás nodos no existe ese nombre o los miembros no superan las comprobaciones (detalles en la descripción del problema). El nodo genera la alerta de código 70 (`reserve-unprotected`).
«Formatos OTT distintos»	Los miembros sirven formatos OTT distintos.
«Sin nombre de host para el servidor OTT»	No se ha indicado el «Nombre de host» del servidor HTTP: los demás nodos reciben la dirección del nodo, y solo por HTTP si el certificado del nodo no está emitido para esa dirección. Es información, no un error.
«Nombre de host del servidor OTT no válido»	El «Nombre de host» del servidor HTTP no es un nombre de host: el nodo no comunica a los demás nodos la dirección de su servidor OTT.
«El reloj de un nodo se desvía demasiado»	El reloj del nodo de otro miembro se desvía más de 240 segundos del reloj de este: ese miembro no puede sustituir a este.
«Aún no hay clave de visualización»	El nodo tiene un miembro de la reserva OTT, pero aún no hay clave de visualización del dominio: los espectadores de este nodo no pasan a otros nodos, y el nodo no acepta espectadores de respaldo. Al cabo de 2 minutos, si la clave puede llegar desde otro nodo, el nodo genera la alerta de código 78 (`reserve-view-key`).
«La clave de visualización no llega a este nodo»	Otros nodos tienen la clave, pero no llega a este nodo; compruebe la conexión entre los nodos del dominio (alerta de código 78).
«Un nodo no ha tomado la clave de visualización»	Un nodo con un miembro de la reserva OTT no confirma la clave vigente durante 10 minutos (alerta de código 78).
«Demasiadas claves de visualización»	El nodo guarda más de cuatro claves de visualización (alerta de código 78).
«Sobrecargado para espectadores de respaldo»	El nodo rechaza a nuevos espectadores de respaldo: la CPU o la red están en el umbral, o se ha alcanzado el «Límite de sesiones de respaldo» (Protección contra sobrecarga).
«Las escaleras de bitrate difieren»	Para algunos escalones de este miembro, el miembro de otro nodo no tiene un escalón con el mismo códec y un bitrate adecuado: en esos escalones no hay respaldo. Un miembro al que durante 60 segundos no le corresponde ningún escalón no se ofrece: la columna «Respaldo» indica «Ninguno de sus escalones corresponde a los de este nodo».
«Un nodo no tiene dirección https para el respaldo»	El nodo del miembro no comunica la dirección HTTPS de su servidor OTT: a los espectadores por HTTPS no se les ofrece como respaldo. Configure en ese nodo el «Nombre de host» del servidor HTTP para el que se ha emitido su certificado.
«Un nodo solo tiene direcciones privadas para el respaldo»	El nodo del miembro solo comunica direcciones privadas: a los espectadores con direcciones públicas no se les ofrece como respaldo.

Paso de los espectadores a otro nodo¶

Desde la versión 2.1.0.458, la playlist master de HLS en vivo de un miembro de un grupo OTT designa hasta dos nodos más del grupo como variantes de respaldo de cada escalón, después de las propias. Un reproductor que admite variantes de respaldo pasa por sí mismo al nodo de respaldo cuando el nodo del espectador deja de servir la ventana en vivo; el espectador no sale del reproductor. Si el flujo del nodo se ha detenido o se ha bloqueado y el respaldo está en vivo, el nodo responde de inmediato a ese espectador con un 404 a la playlist, y el reproductor cambia sin esperar a sus propios tiempos de espera. Los espectadores de un nodo que ha fallado se reparten entre sus respaldos.

Reproductores. Reciben variantes de respaldo los reproductores que saben usarlas: AVPlayer (Safari, iOS, tvOS), hls.js y reproductores similares en el navegador, ExoPlayer y Media3. Los reproductores que no saben cambiar de este modo (VLC, mpv, Kodi, GStreamer, reproductores basados en ffmpeg, decodificadores sin User-Agent) reciben la playlist master sin líneas de respaldo y funcionan como antes; cuántas playlists master de ese tipo se han servido lo muestra la fila «Listas maestras sin respaldo» del bloque «Clave de visualización OTT». Qué recibe cada reproductor y qué se ha comprobado: Reproductores y reserva OTT/DVR; qué tener en cuenta en la caché y la CDN: 8.1. Reserva OTT/DVR y CDN. La aplicación propia del operador puede solicitar los respaldos con el parámetro rsv=1 en la dirección de la playlist master o renunciar a ellos con el parámetro rsv=0.

Para hls.js, configure tiempos de espera cortos de carga de playlist y de segmento, de alrededor de una duración objetivo de segmento, 2–3 segundos: así el reproductor abandona rápidamente un nodo bloqueado.

Qué nodo se convierte en respaldo. Un nodo se designa como respaldo solo si su miembro puede sustituir al miembro de este nodo (columna «Respaldo»: «Puede respaldar») y, en el momento de la solicitud:

ha servido recientemente la ventana en vivo y sirve HLS;
su reloj no difiere del de este nodo en más de 240 segundos;
los nodos comparten la clave de visualización (más abajo);
el nodo no está sobrecargado (Protección contra sobrecarga);
tiene un escalón con el mismo códec;
el espectador puede llegar a él del mismo modo: un espectador por HTTPS necesita una dirección HTTPS del nodo de respaldo, y un espectador con dirección pública, una dirección pública. Por eso, configure el «Nombre de host» del servidor HTTP en cada nodo (Servidor HTTP de streaming).

Clave de visualización. El nodo de respaldo acepta al espectador de otro nodo mediante un pase vinculado a la sesión del espectador, a su nodo, al flujo y al tiempo. Los pases se firman con la clave de visualización, común a los nodos del dominio con miembros de la reserva OTT. No hace falta configurar nada: la clave se crea sola, cambia cada 7 días y se guarda solo en memoria; su estado lo muestra el bloque «Clave de visualización OTT» de la pestaña «Estado», y el botón «Cambiar la clave de visualización» la cambia manualmente. Si la clave no llega a un nodo, el nodo genera la alerta de código 78 (reserve-view-key).

Limitaciones de esta versión beta. Solo reciben variantes de respaldo los flujos individuales cuyos miembros en distintos nodos toman una misma fuente (paso «Misma línea de tiempo»). Los conjuntos adaptativos, LL-HLS y DASH se agrupan y se muestran, pero todavía no tienen respaldos en la playlist master ni en el manifiesto; a esos espectadores solo los protege la redirección al abrir (Redirección de los espectadores). Los subtítulos permanecen en el nodo de origen después del cambio. La playlist master de archivo y de catch-up no designa respaldos: el archivo de otros nodos el espectador lo obtiene mediante redirección.

Redirección de los espectadores¶

Desde la versión 2.1.0.459, el nodo redirige al espectador a otro nodo del grupo OTT (respuesta 302) ya al abrir la playlist master HLS y LL-HLS o el manifiesto DASH. La redirección no requiere soporte del reproductor: la siguen todos los reproductores, incluidos VLC y los decodificadores, y para DASH es la única protección de la emisión en vivo en esta versión beta. Funciona para los flujos y los conjuntos adaptativos con la «Reserva OTT» activada.

Catch-up desde el archivo de otros nodos. Si el espectador pide un periodo pasado que no está en el archivo de este nodo, el nodo lo envía al nodo del grupo que guarda la mayor parte del periodo; la profundidad del archivo puede variar entre nodos. Si ningún nodo guarda el periodo, el espectador recibe 404 (reserve: no recording for this period); antes, una playlist vacía. Para HLS se tiene en cuenta el archivo MPEG-TS; para LL-HLS y DASH, el archivo fMP4.

El paso al archivo de otro nodo se decide según el rango del archivo, desde la grabación más antigua hasta la más reciente. Si el inicio del periodo solicitado cae dentro del rango del archivo de este nodo, atiende al espectador el propio nodo, aunque en ese momento su archivo tenga un hueco (por ejemplo, mientras la entrada no funcionaba): los huecos dentro del rango no se trasladan a otro nodo.

Espectadores nuevos de un flujo que aquí no funciona. Al espectador que abre un flujo que en este nodo no funciona (detenido o en pausa, con error, con la entrada caída o todavía sin imagen) el nodo lo envía a un nodo donde ese flujo está en vivo. Un flujo que apenas está arrancando no se ve afectado: en cuanto aparece un segmento en su ventana en vivo, a los espectadores los atiende este nodo. Un nodo reiniciado con el flujo en pausa no redirige a espectadores nuevos hasta que el flujo haya funcionado al menos una vez.

Primero el login. En los flujos con la «Reserva OTT» activada, el login del espectador se comprueba antes que nada: con una contraseña incorrecta la respuesta es siempre 403, aunque el flujo no funcione. Los demás flujos responden como antes.

Límite de conexiones. «Conexiones máx., HTTP/HLS» del login (Usuario: añadir y editar) se aplica en cada nodo por separado: un abonado redirigido puede abrir otras tantas sesiones también en otro nodo.

El nodo se elige igual que el respaldo para el cambio (Paso de los espectadores a otro nodo), pero no se comprueban el reproductor ni el nivel de paso, por lo que también sirven los conjuntos adaptativos y LL-HLS. La red del espectador no se tiene en cuenta al elegir el nodo para catch-up: el otro nodo debe ser accesible para el espectador del mismo modo; para HTTPS hace falta una dirección HTTPS.

Protección contra sobrecarga¶

Un nodo de respaldo acepta a un nuevo espectador de otro nodo (espectador de respaldo) solo mientras tiene margen: la carga de CPU del host y de la interfaz de red está por debajo de los umbrales de error de esos recursos en los ajustes de alertas (Alertador), y el número de sesiones de respaldo no ha alcanzado el «Límite de sesiones de respaldo» de la pestaña «Ajustes» (0 = sin límite; se aplica de inmediato). Un umbral 0 desactiva su comprobación. El nodo nunca rechaza a sus propios espectadores ni las sesiones de respaldo ya abiertas. Al recibir un rechazo, el reproductor pasa al siguiente respaldo, y los demás nodos dejan de designar temporalmente como respaldo al nodo sobrecargado.

El bloque «Protección OTT contra sobrecarga» de la pestaña «Estado» muestra si hay margen, las causas de la sobrecarga, el margen de red y de sesiones, los umbrales, el número de sesiones de respaldo y de rechazos. Mientras la causa persiste, los grupos OTT del nodo tienen el problema «Sobrecargado para espectadores de respaldo». Si el nodo rechaza a nuevos espectadores de respaldo durante 30 segundos seguidos, genera la alerta de código 79 (reserve-ott-overload); la alerta se retira tras 60 segundos sin rechazos.

Pantalla «Reservas»¶

La pantalla muestra los grupos en los que este nodo tiene un miembro; los demás nodos muestran los suyos. Si la reserva está desactivada en el nodo, la pantalla explica cómo activarla y ofrece el enlace «Abrir ajustes».

Pestaña «Estado».

Las tarjetas «Grupos», «Grupos con problemas», «Errores», «Avisos», «Nodos en el canal» y «Grupos por estado».
El bloque «Canal de control de este nodo»: estado del canal, relojes («Sincronizado» o «No sincronizado»), huella de la clave, nodos votantes, cuarentena y «Tiempos»: toma de control, ventana y retardo; los contadores «Grupos OTT» y «Informes no enviados» (informes que no cupieron en un datagrama o se aplazaron a la siguiente ronda).
La tabla «Nodos»: una fila por cada nodo del canal: «Canal», «Clave», «RTT, ms», «Desfase del reloj, ms», «Pérdida, %», «Última respuesta» y «Versión».
La lista «Grupos». De cada grupo: el estado, el rol de este nodo, el emisor y el número de elección, los miembros con su prioridad, rol, la marca «Emite» y el resultado de la comparación del origen, el bloque «Salida de este nodo» y la lista de problemas. Estados del grupo: «Solo» (los demás miembros no informan de sí), «Formándose» (miembros encontrados y en comprobación), «Discrepancia» (los miembros tienen distinto tipo de flujo o distinta marca de canal cifrado) y «Conflicto» (alguien que no pertenece al grupo envía a él).

Rol de este nodo en el grupo: «Emisor», «En reserva», «Compite», «Solo», «No listo», «Cuarentena», «Espera la clave del dominio», «Emisor sin confirmar», «Apartado», «Liberado», «Cediendo el rol», «Asumiendo el rol», «Sin verificar» o «Ninguno».

El bloque «Salida de este nodo» muestra si la salida está abierta («Abierta: este nodo emite» o «Cerrada: emite otro miembro»), si está alineada con la escala de tiempo del grupo, el margen, el retardo, el FEC de grupo de una salida Pro-MPEG y los contadores de datagramas. Los contadores crecientes de datagramas tardíos, desbordamientos y errores de envío se resaltan; un miembro de reserva rezagado se marca: la conmutación a él no será transparente.

Pestaña «Ajustes». Los campos «Reserva Meshwork», «Solo emite el emisor elegido (reserve-gate)», «Puerto UDP del canal de control» (1024–65535, 43975 por defecto), «Interfaz del canal de control» («Todas las interfaces» por defecto), «Retardo de salida (ms)», «Devolver tras (s)», «Límite de sesiones de respaldo» (Protección contra sobrecarga) y «Interfaz de testigo» (para un nodo que solo vota; en esta versión aún no se usa). La activación de la reserva, el modo, el puerto y la interfaz se leen al arrancar el servicio: los cambios tienen efecto tras un reinicio.

Problemas del grupo¶

Problema	Qué significa
«Conflicto de dirección»	Envía al grupo un origen que no pertenece a él (alerta de código 71, `reserve-address-conflict`).
«Dos emisores»	Dos miembros envían al grupo a la vez (alerta de código 67, `reserve-two-senders`). En el modo de observación es un aviso: allí envían todos.
«Ajustes distintos»	Los miembros tienen distinto «Tipo de flujo» o distinta marca de canal cifrado.
«El contenido contradice los ajustes»	El flujo de un miembro no corresponde a sus ajustes: por ejemplo, hay vídeo con el tipo de flujo «Solo audio». Mandan los ajustes.
«Origen no probado igual»	El origen de un miembro no se puede cotejar durante 30 segundos (alerta de código 68, `reserve-source-mismatch`).
«El descifrado difiere»	Las partes en claro de los flujos coinciden, pero el contenido no: uno de los nodos no descifra.
«Marcas de tiempo propias, sin etiqueta de origen»	La entrada del miembro pone ella misma las marcas de tiempo: configure la misma «Etiqueta de origen de reserva».
«Miembro no verificado»	Un nodo anuncia un miembro, pero sus informes no llegan a este nodo.
«Dos salidas de este nodo»	Dos salidas de un mismo nodo envían a un mismo grupo.
«Falta la interfaz de salida multicast»	La salida miembro no tiene definida la interfaz de envío.
«Este nodo no ve el grupo»	Este nodo no puede observar el grupo; los detalles están en la descripción del problema.
«MPTS listado, no reservado»	Una salida MPTS se muestra en el grupo, pero no se reserva.
«Entrada DVB, aún sin probar»	El flujo procede de una entrada DVB.
«La ruta 2 difiere entre miembros»	La segunda ruta de un miembro va a otra dirección o no está definida.
«Retardo de reserva menor que la espera de fusión»	El retardo de salida es menor que la ventana de espera de la segunda ruta de la entrada más 400 ms.
«Miembro ProMPEG sin compuerta: matriz o packets»	La salida Pro-MPEG no participa en la selección del emisor: «columnas × filas» no es una potencia de dos, o el datagrama no lleva 7 paquetes TS. Envía siempre, junto al emisor del grupo, y no asume el grupo.
«Miembro ProMPEG sin compuerta: multiplexación o frase de paso»	Lo mismo, en una salida con multiplexado o frase de contraseña.
«La matriz FEC ProMPEG difiere»	La matriz FEC de un miembro difiere, o su versión no la comunica: cambiar a él modifica la matriz en los receptores.

Las alertas de reserva, códigos 66–74, 78 y 79, se enumeran en Reserva de flujos.