Dante unicast vs multicast: elige el flujo de audio correcto

TL;DR — Dante usa unicast por defecto: un flujo de medios sirve a un solo dispositivo receptor. Multicast envía un flujo configurado que varios receptores pueden unirse. Usa unicast para suscripciones punto a punto normales; considera multicast cuando varios receptores necesiten los mismos canales del transmisor o cuando la capacidad de flujos de transmisión sea el límite. Multicast puede propagarse por todos los enlaces de red si no se gestiona correctamente con IGMP. Cuenta receptores, flujos, canales y ancho de banda de los enlaces, y después prueba los destinos reales antes de documentar la decisión.

Unicast y multicast resuelven problemas de fanout distintos

Una suscripción de Dante conecta un canal receptor con un canal transmisor. La red transporta esas suscripciones en flujos. Un flujo unicast va de un transmisor a un solo dispositivo receptor. Un flujo multicast se crea en el transmisor y puede servir a varios dispositivos receptores.

No confundas el multicast de medios con el tráfico de descubrimiento y reloj de Dante. Una red puede usar protocolos multicast aunque todas las suscripciones de audio sean unicast. La decisión de producción aquí es si unos canales de medios concretos deben colocarse en un flujo de transmisión multicast de Dante.

Empieza con unicast para suscripciones normales

Unicast es el valor por defecto más simple porque Dante Controller crea y elimina los flujos necesarios a medida que los receptores se suscriben y se dan de baja. El tráfico se dirige hacia el dispositivo receptor en lugar de distribuirse intencionadamente a muchos oyentes.

Usa unicast cuando:

• uno o dos dispositivos necesitan una fuente;
• grupos de receptores necesitan conjuntos de canales distintos;
• el transmisor tiene suficientes flujos disponibles;
• la ruta cruza un enlace donde el tráfico multicast innecesario sería costoso;
• el sistema es lo bastante pequeño como para que el enrutado automático sea fácil de revisar.

Un flujo unicast suele transportar varios canales de audio de un transmisor a un receptor, pero las capacidades exactas de flujos y canales dependen del dispositivo transmisor y del firmware. No calcules un show a partir de un número genérico solamente. Comprueba la capacidad de flujos de transmisión anunciada por el dispositivo en Dante Controller y confirma las rutas previstas en el hardware real.

Usa multicast cuando muchos receptores necesiten los mismos canales

Multicast puede reducir el fanout del transmisor cuando el mismo programa debe llegar a muchos destinos. Un flujo multicast configurado puede alimentar amplificadores, grabadores, interfaces de broadcast y dispositivos de monitorización que se unan a él. Añadir otro receptor no requiere otra copia desde el transmisor.

Buenos candidatos incluyen:

• un par de programa distribuido a muchos puntos de amplificación;
• un canal de paging o anuncios requerido por muchas zonas;
• una señal de broadcast compartida por varios dispositivos receptores;
• una fuente repetida que de otro modo superaría la capacidad de flujos del transmisor;
• flujos AES67 u otros flujos RTP cuyo diseño de interoperabilidad requiera multicast.

No crees un flujo enorme solo porque multicast esté disponible. Agrupa únicamente los canales que los receptores necesiten realmente juntos. Un receptor que se une a un canal de un flujo puede hacer que la red transporte todo el flujo a lo largo de esa ruta. Los grupos más pequeños y con propósito son más fáciles de nombrar, medir y eliminar con seguridad.

Cuenta el fanout antes de cambiar la ruta

Construye una matriz de receptores antes de configurar multicast:

Para cada transmisor, registra sus flujos de transmisión disponibles, flujos actuales, receptores previstos, canales por receptor, velocidad del enlace y ancho de banda medido. Una advertencia de fanout significa que la ruta merece revisión; no prueba que multicast sea automáticamente seguro. El nuevo tráfico multicast sigue teniendo que cruzar todos los enlaces necesarios.

Controla multicast en la capa de switching

Sin gestión de multicast, un switch puede reenviar medios a puertos que nunca los solicitaron. Eso puede desperdiciar capacidad en enlaces de 100 Mbps, puentes Wi‑Fi, ordenadores de control y dispositivos con interfaces limitadas.

Las redes gestionadas suelen usar IGMP snooping para que los switches aprendan qué puertos solicitaron un grupo multicast. La red también necesita una función de querier correctamente diseñada para que el estado de membresía siga siendo válido. Los detalles de configuración varían según la plataforma de switch, la topología y la VLAN, así que sigue el diseño de red aprobado en lugar de copiar los menús de un solo fabricante.

Comprueba estos límites:

1. ¿Qué switch o router asume el rol de querier de IGMP?
2. ¿Está snooping habilitado de forma coherente en la red relevante?
3. ¿Todos los trunks y puertos de acceso transportan el grupo previsto?
4. ¿Las rutas inalámbricas, de 100 Mbps, de control o de uplink están protegidas frente a medios no deseados?
5. ¿La red redundante repite la configuración necesaria de forma independiente?

La guía de Dante redundante frente a conmutado explica por qué las redes primaria y secundaria deben permanecer separadas. La configuración de multicast no justifica unirlas.

Prueba la ruta y su comportamiento ante fallos

1. Guarda la línea base

Registra nombres de dispositivos, suscripciones, flujos activos, frecuencia de muestreo, latencia, líder de reloj, grupos multicast, configuración del switch y ancho de banda antes de hacer cambios.

2. Demuestra el estado unicast

Confirma que cada destino recibe los canales correctos. Anota el uso de flujos del transmisor y el ancho de banda en cada enlace importante.

3. Crea solo el flujo multicast previsto

Elige exactamente los canales del transmisor, nombra el propósito y observa qué receptores existentes pasan de unicast a multicast. No asumas que la transición ocurrió; inspecciona el estado de suscripciones y flujos.

4. Comprueba cada segmento de red

Mide los puertos de switch y los enlaces con limitaciones con todos los receptores activos. Confirma que multicast aparece solo donde se requiere cuando la gestión IGMP forma parte del diseño.

5. Elimina y restaura receptores

Desconecta o cancela la suscripción de un destino cada vez. Confirma que los receptores restantes continúan, que la membresía se actualiza correctamente y que el endpoint eliminado no deja un estado de tráfico o enrutado inesperado.

6. Ensaya la reversión

Antes de borrar un flujo multicast, calcula si el transmisor puede recrear todos los flujos unicast resultantes. Elimina rutas de forma controlada si hace falta, restaura la línea base y verifica el audio otra vez.

Deja la propiedad de los flujos en el rider técnico

Un traspaso útil nombra el transmisor, los canales, el tipo de flujo, los receptores, el responsable del switch, el diseño de IGMP, los enlaces con limitaciones, la línea base de ancho de banda, la ventana de prueba y la reversión. “Usa Dante multicast” no es una instrucción construible.

En Techrider.live, alinea los nombres de flujo con las listas de entrada y salida, invita a los ingenieros de sistema y de broadcast a editar el mismo rider técnico, guarda la matriz de receptores aceptada, revisa el historial después de un cambio de enrutado y exporta un PDF fechado para el load-in.

Lista de comprobación de flujos Dante

• Se conoce la capacidad real de flujos de cada transmisor.
• Los receptores que necesitan canales idénticos están listados.
• Se mantiene unicast donde el fanout es pequeño o los conjuntos de canales difieren.
• Los grupos multicast contienen solo los canales que deben ir juntos.
• El snooping IGMP y la propiedad del querier están documentados donde se usan.
• El ancho de banda se mide en uplinks e interfaces con limitaciones.
• Se prueban el estado de suscripción, el reloj, la latencia, los errores, la pérdida y la reversión.

FAQ

¿Cuál es la diferencia entre Dante unicast y multicast?

Unicast envía un flujo de medios desde un transmisor a un solo dispositivo receptor. Multicast crea un único flujo del transmisor al que pueden unirse varios dispositivos receptores. Unicast es automático por defecto; multicast se configura deliberadamente.

¿Cuándo deberías usar multicast en Dante?

Considera multicast cuando varios receptores necesiten los mismos canales, el transmisor se acerque a su límite de flujos o un diseño de interoperabilidad lo requiera. Verifica el comportamiento del switch y el ancho de banda antes de cambiar la ruta.

¿Dante usa multicast por defecto?

Las suscripciones de medios de Dante usan unicast por defecto. El descubrimiento y el clocking de Dante también usan protocolos de red que incluyen tráfico multicast, pero eso es distinto de elegir un flujo de medios multicast.

¿Dante multicast requiere IGMP snooping?

El audio puede pasar sin snooping, pero entonces multicast puede inundar puertos de switch innecesarios. En redes de producción gestionadas, un IGMP snooping correctamente diseñado y un querier suelen mantener los medios en los enlaces requeridos. Sigue el diseño del switch y del sistema.

¿Cómo pruebas el audio multicast de Dante?

Guarda la línea base, verifica cada receptor, inspecciona el estado de los flujos, mide todos los enlaces importantes, confirma la poda IGMP donde se espere, elimina y restaura destinos, y ensaya una vuelta controlada a unicast.

Haz visible el fanout antes del load-in

Crea un único rider técnico que nombre cada canal fuente, receptor, tipo de flujo, frontera de switch, prueba, responsable y reversión antes de que las suscripciones repetidas saturen la red.