Dante PTP v1 vs PTP v2: mantén compatibles los dominios de reloj

Resumen rápido — PTPv1 y PTPv2 son protocolos de temporización distintos, no etiquetas intercambiables. Un sistema Dante puede usar un comportamiento de PTP diferente en un límite nativo de Dante y en un límite de interoperabilidad AES67, según el dispositivo y la compatibilidad de firmware. Haz inventario de cada endpoint, identifica cada dominio de reloj y su puente autorizado, verifica los estados reales de líder y seguidor, y luego prueba el audio ante pérdida y recuperación. No des por hecho que ver un stream implica compatibilidad de reloj.

Empieza por el dominio de reloj, no por el stream

Precision Time Protocol distribuye una referencia temporal compartida por la red. La versión del protocolo forma parte de ese límite de temporización. Los dispositivos que participan en distintas versiones de PTP no se convierten automáticamente en un único dominio de reloj solo porque compartan un switch o puedan descubrir el mismo flujo de medios.

Usa la guía de líder de reloj de Dante para los fundamentos de la elección. Esta guía se ocupa del límite de versión y de su prueba de aceptación.

Entiende PTPv1 y PTPv2 como protocolos separados

PTPv1 y PTPv2 usan formatos de mensaje y comportamientos de elección distintos. Trátalos como sistemas de temporización diferentes salvo que la documentación exacta del producto indique que un dispositivo admite un límite deliberado o un modo de interoperabilidad.

La sincronización nativa de Dante y la interoperabilidad AES67 pueden tener requisitos distintos. No conviertas esa afirmación general en una regla fija para cada producto. Confirma el modo PTP admitido, el comportamiento del dominio, la frecuencia de muestreo y la implementación AES67 para cada dispositivo y cada versión de firmware.

Haz inventario de los endpoints antes de configurar

1. Registra cada transmisor, receptor, ruta de switch, versión de firmware y modo de interoperabilidad habilitado.
2. Anota la frecuencia de muestreo de audio y el comportamiento PTP admitido para cada endpoint.
3. Dibuja cada dominio de reloj por separado, incluido su líder esperado y sus seguidores.
4. Identifica cualquier dispositivo pensado para participar en o hacer de puente entre más de un contexto de temporización.
5. Verifica que el rol propuesto esté admitido explícitamente por la documentación actual del fabricante.
6. Guarda la línea base sana: líder, estados de seguidor, offsets, suscripciones, eventos y salida audible.

No actives un segundo modo de protocolo en todos los dispositivos como solución exploratoria. Cambia solo el dispositivo de límite documentado y mantén una ruta de vuelta.

Construye un único límite de temporización deliberado

Nombra al líder en cada dominio

Anota el líder esperado, el comportamiento alternativo y los ajustes de preferencia para cada dominio. Un puente no puede compensar dos elecciones inestables.

Alinea el formato de medios

Confirma que el emisor y el receptor admiten la misma frecuencia de muestreo, codificación, número de canales y modo de interoperabilidad. Un receptor compatible con el reloj puede seguir rechazando una carga útil no admitida.

Controla el alcance de la red

Mapea las VLAN, los puertos de switch, el forwarding multicast y cualquier límite enrutado. Mantén las redes primaria y secundaria de Dante separadas según el diseño admitido. Un experimento con PTP no debe unir rutas redundantes ni extender el tráfico de temporización sin querer.

Verifica el límite por capas

Empieza por la temporización. Confirma el líder esperado y los seguidores estables en cada lado; después inspecciona offsets y eventos el tiempo suficiente para detectar elecciones repetidas o desbloqueos. A continuación confirma el flujo de medios, el mapeo de canales y el destino físico. Por último, envía audio identificable canal por canal.

La guía de configuración de flujos AES67 cubre el flujo de trabajo de medios una vez establecida la compatibilidad de temporización.

Prueba la pérdida, la recuperación y el reinicio

1. Reproduce audio representativo y captura el estado estable en ambos lados.
2. Interrumpe el límite aprobado en un único punto conocido.
3. Registra cambios de líder, desbloqueos de seguidor, comportamiento de muteo o artefactos y marcas de tiempo de eventos.
4. Restaura el límite y espera una recuperación estable del reloj antes de evaluar el audio.
5. Verifica de nuevo cada suscripción y cada salida física crítica.
6. Reinicia siguiendo la secuencia aprobada y confirma que el estado previsto persiste.
7. Ejecuta la vuelta atrás para que el equipo pueda regresar a la línea base nativa de Dante.

No describas la recuperación como transparente salvo que el sistema exacto desplegado lo haya demostrado con carga realista.

Lista de comprobación de aceptación del límite PTP

• Cada dispositivo, versión de firmware y modo PTP admitido está registrado.
• Cada dominio de reloj tiene un líder esperado y un comportamiento alternativo documentado.
• Cualquier rol de puente o de interoperabilidad está admitido por el fabricante.
• La frecuencia de muestreo, la codificación, el número de canales y el mapeo del receptor coinciden.
• El alcance de VLAN y multicast transporta temporización solo donde está previsto.
• Los seguidores permanecen estables y los offsets son aceptables bajo carga de producción.
• El audio identificable llega a cada destino físico crítico.
• Se han demostrado la pérdida, la recuperación, la persistencia tras reinicio y la vuelta atrás.
• El responsable y las pruebas aceptadas están adjuntos al handoff.

Documenta el handoff de temporización

Registra dispositivos, firmware, modos de protocolo, dominios, líderes, preferencias, rutas de red, formato de medios, offsets, evidencias de eventos, resultados audibles, comportamiento ante fallos, secuencia de reinicio, responsable y vuelta atrás. Haz que el diagrama distinga los dominios de temporización de los flujos de medios.

Guarda el mapa de reloj aceptado junto al patch digital y la lista de canales en Techrider.live. Invita a los colaboradores a editar el mismo rider, guarda la versión probada, revisa el historial y exporta un PDF actualizado para el equipo de recinto, broadcast o gira.

FAQ

¿Dante usa PTPv1 o PTPv2?

El comportamiento de temporización de Dante depende del producto, del firmware y del modo operativo. El Dante nativo y un límite de interoperabilidad AES67 pueden usar contextos de PTP distintos, así que confirma la documentación y el estado reales del dispositivo en lugar de confiar en una etiqueta universal.

¿Pueden sincronizarse directamente dispositivos PTPv1 y PTPv2?

No lo des por hecho. Son protocolos distintos. Un dispositivo o una arquitectura admitidos deben gestionar deliberadamente el límite; de lo contrario, trátalos como dominios de reloj separados.

¿Por qué un stream AES67 se ve pero no se sincroniza?

El descubrimiento y la temporización de medios son cosas distintas. El receptor puede ver la información de sesión mientras usa un modo PTP incompatible, sin bloqueo de reloj o rechazando el formato de medios seleccionado.

¿Puede un solo dispositivo hacer de puente entre dominios de reloj PTP?

Solo cuando ese dispositivo, firmware y configuración exactos admiten explícitamente ese rol. Verifica su comportamiento, el estado de líder, las limitaciones de formato y la recuperación ante fallos en el sistema desplegado.

¿Cómo pruebo un límite de PTP en Dante?

Confirma líderes y seguidores estables en ambos lados, reproduce audio identificable, inspecciona offsets y eventos bajo carga, interrumpe un único límite aprobado y demuestra después la recuperación, la persistencia tras reinicio y la vuelta atrás.