Dante und AES67

Offener Standard versus kommerzielles Ökosystem

AES67 wird als öffentlicher Standard gepflegt. Sein Zweck ist es, eine gemeinsame Interoperabilitätsoberfläche zu definieren, die viele Hersteller implementieren können, ohne Controller, Discovery-Modell oder Produktfamilie eines einzelnen Unternehmens zu übernehmen. Dante ist ein kommerzielles Technologie-Ökosystem, das Audinate besitzt und entwickelt. Es bietet ein vollständiges Anwendererlebnis über Erkennung, Routing, Taktgebung, Gerätemanagement, virtuelle Soundkarten, Software und zertifizierte Hardware hinweg.

Dieser Unterschied ist bei keinem der Modelle ein Mangel. Ein Standardisierungsgremium kann eine dauerhafte gemeinsame Schicht definieren, aber nicht das Anwendererlebnis jeder Implementierung garantieren. Ein kommerzielles Ökosystem kann eng integrierte Werkzeuge und vorhersagbares Verhalten liefern, bleibt aber unter der Kontrolle seines Eigentümers.

Die Dante-AES67-Interoperabilität ist daher am besten als Treffpunkt zwischen diesen Modellen zu sehen. Dante-Geräte können ausgewählte Streams in AES67-kompatibler Form bereitstellen, und AES67-Geräte können diese Streams empfangen oder senden. Der Rest des Dante-Workflows bleibt Dante-spezifisch.

Eigentum und Markenkontext

AES67 entsteht durch die Standardisierungsarbeit der AES. Dante und die zugehörigen Namen, Logos und technischen Spezifikationen werden von Audinate kontrolliert. Ein Produkt, das die Dante-AES67-Interoperabilität unterstützt, wird damit nicht Open Source, und eine AES67-Implementierung wird per Definition kein Dante-Produkt.

Markengenauigkeit zählt in technischen Texten. Verwenden Sie Dante nur für die Technologie von Audinate und die offiziellen Produktnamen des Herstellers, wenn Sie ein bestimmtes Gerät oder einen Modus meinen. Vermeiden Sie die Andeutung, AES67 gehöre Dante oder Dante sei ein generisches Synonym für AoIP.

Dante ist eine Marke der Audinate Pty Ltd. Diese Seite ist ein unabhängiger technischer Vergleich.

Die Markenangabe ist redaktioneller Kontext, kein Ersatz für die Prüfung der aktuellen Bedingungen des Lieferanten.

Discovery, Routing und Steuerung

Native Dante-Geräte werden üblicherweise über das Dante-Control-Ökosystem erkannt und je nach Produkt und Installation mit Werkzeugen wie Dante Controller oder Dante Director verwaltet. Der Anwender sieht Gerätenamen, Kanalbezeichnungen, Subskriptionen, Taktstatus und Diagnose in einer einheitlichen Oberfläche.

AES67 definiert kein universelles Discovery- oder Routing-Protokoll. Betreibt Dante einen AES67-Interoperabilitätsmodus, kann der Audiostream für ein externes System über eine Sitzungsbeschreibung oder einen kompatiblen Discovery-Mechanismus sichtbar sein – das bedeutet aber nicht, dass jede Dante-Funktion im externen Controller verfügbar wird.

Integratoren sollten zwei Schichten dokumentieren: die Audio-Flows, die die AES67-Grenze überschreiten, und die Verwaltungsaktionen, die nativ bleiben. Ein nützliches Hybrid-Diagramm zeigt Dante Controller auf der einen Seite, das AES67-Gerät oder den AES67-Controller auf der anderen sowie die genauen Punkte, an denen SDP, Multicast-Adressen, PTP-Konfiguration und Kanalzuordnung ausgetauscht werden.

Taktgebung, Latenz und Redundanz

Dante nutzt ein eigenes Taktmodell und bietet konfigurierbare Latenzeinstellungen für native Flows. Der AES67-Modus kann eine andere Paketzeit- oder Latenzeinstellung erzwingen, weil der Interoperabilitätsvertrag zum externen Gerät passen muss. Ein erfolgreiches Design sollte auf beiden Seiten der Verbindung dieselbe Abtastrate, Paketzeit und Taktbeziehung verwenden.

Latenz ist keine einzelne Zahl. Sie umfasst Paketierung, Empfängerpufferung, Geräteverarbeitung, Netzwerklaufzeit und jede Wandlung zwischen nativem und Interoperabilitätsmodus. Der sicherste Vergleich ist die Ende-zu-Ende-Latenz, gemessen in der realen Topologie – nicht der niedrigste Wert auf einem Datenblatt.

Dante bietet Redundanzoptionen innerhalb seines Ökosystems, während AES67 selbst keinen universellen nahtlosen Schutzmechanismus definiert. Eine hybride Installation kann die native Redundanz innerhalb der Dante-Domäne erhalten und an der AES67-Grenze ein anderes Schutzmodell zeigen. Das Ausfallverhalten dieser Grenze muss getestet und dokumentiert werden.

Die PTP-Abstimmung ist ebenso wichtig. Dante-Geräte und AES67-Geräte müssen möglicherweise eine Taktreferenz teilen oder kontrolliert zwischen Zeitdomänen überbrücken. Schlechte PTP-Planung kann intermittierendes Audio erzeugen, selbst wenn Routing und Bandbreite korrekt erscheinen.

Verwaltung und Support

Das native Dante-Management umfasst mehr als Audio-Subskription. Es schließt Gerätenamen, Kanalbezeichnungen, Taktüberwachung, Firmware-Workflows, Ereignisprotokolle und den Zugang zu Audinate-Diensten oder -Software ein. Der AES67-Interoperabilitätsmodus legt diese Verwaltungsfunktionen nicht automatisch für ein Drittsystem offen.

Ein hybrides Projekt sollte festlegen, wer jede Schicht verantwortet. Wer vergibt Dante-Gerätenamen? Wem gehören die AES67-Multicast-Adressen? Wer überwacht PTP? Wer erhält Alarme, wenn ein Stream verschwindet? Wer aktualisiert die Firmware auf beiden Seiten der Grenze? Unklare Zuständigkeiten sind eine häufige Ursache für langsame Fehlerbehebung.

Auch Support-Grenzen sollten explizit sein. Ein Hersteller kann das Dante-Gerät, den AES67-Modus und die Netzwerkkonfiguration getrennt unterstützen und zugleich die Verantwortung für einen Drittanbieter-Controller oder ein nicht standardgemäßes Switch-Design ablehnen. Eine schriftliche Integrationsmatrix reduziert das Zuschieben von Verantwortung während Inbetriebnahme und Betrieb.

Zertifizierung und Konformitätsaussagen

Dante-Produkte nehmen am Produkt- und Zertifizierungsprogramm von Audinate teil, und der verfügbare Funktionsumfang kann nach Geräteklasse, Hardware, Firmware und Lizenz variieren. Die AES67-Unterstützung sollte gegen das genaue Modell und die Firmware-Version verifiziert werden, statt aus der Dante-Marke abgeleitet zu werden.

Eine nützliche Konformitätsprüfung stellt vier Fragen: Unterstützt das Gerät die erforderliche AES67-Stream-Richtung? Unterstützt es Abtastrate und Paketzeit? Stellt es die benötigte Kanalzahl bereit? Passt sein Takt- und Redundanzverhalten zum Systemdesign? Eine fünfte Frage ist, ob der Hersteller die Grenzen des Interoperabilitätsmodus dokumentiert.

Eine Zertifizierung ist ein Nachweis für eine bestimmte getestete Konfiguration, kein Beweis, dass jede Kombination sich identisch verhält. Bewahren Sie Firmware-Version, Konfigurationsexport, Testskripte und Messergebnisse mit der Projektdokumentation auf.

Was der Dante-AES67-Modus verändert

In einer typischen Dante-AES67-Installation werden ausgewählte Sende- oder Empfangs-Flows so konfiguriert, dass sie einen AES67-kompatiblen Transport und eine entsprechende Timing-Beziehung nutzen. Das kann einem Dante-Netzwerk erlauben, einen Nicht-Dante-Prozessor, ein Broadcast-Gerät, ein Aufnahmesystem oder eine andere AoIP-Plattform zu versorgen, die dasselbe Interoperabilitätsprofil unterstützt.

Die Grenze ist üblicherweise schmaler als der native Workflow. Ein AES67-Empfänger kennt nicht zwangsläufig den Dante-Gerätenamen, die Kanalbezeichnungen oder das Subskriptionsmodell. Er sieht womöglich nur einen per SDP beschriebenen IP-Stream. Umgekehrt kann der Dante-Controller möglicherweise nicht jede Eigenschaft des externen Empfängers verwalten.

Manche Funktionen können sich auch ändern, wenn ein Gerät den nativen Dante-Modus verlässt. Kanalzahlen können geringer sein, Latenzeinstellungen begrenzt, Abtastraten eingeschränkt und das Redundanzverhalten anders. Diese Einschränkungen sind implementierungsspezifisch und sollten in der aktuellen Produktdokumentation bestätigt werden.

Einschränkungen, die Sie einplanen sollten

Die größte Einschränkung ist nicht immer die Bandbreite, sondern die betriebliche Sichtbarkeit. Ein Dante-Bediener sieht vielleicht ein gesundes natives Netzwerk, während eine AES67-Querverbindung ausgefallen ist; oder ein AES67-Controller zeigt einen Stream, ohne zu wissen, dass seine Dante-Quelle in einen gestörten nativen Zustand geraten ist. Domänenübergreifendes Monitoring ist unverzichtbar.

Das Multicast-Design ist ein weiteres häufiges Risiko. Dante, AES67 und das umgebende Netzwerk können unterschiedliche Konventionen für Adressvergabe, IGMP-Verhalten und Streamdichte haben. Ein sauberer Multicast-Plan sollte Bereiche reservieren, Gruppenmitgliedschaften begrenzen und das Querier-Verhalten in jedem VLAN prüfen.

Schließlich ist eine Dante-AES67-Verbindung kein universeller Konverter für jedes Format oder jede Steuerungsfunktion. Sie verwandelt keine Nicht-Audio-Signale in Audio, ersetzt keinen Abtastratenwandler und garantiert nicht, dass ein Drittanbieter-Gerät ein Dante-Produkt steuern kann. Diese Funktionen erfordern eigene Produkte oder eine Management-Integration.

Reine Dante- und hybride Installationen

Eine reine Dante-Installation ist meist die einfachste Option, wenn jeder kritische Endpunkt aus dem Dante-Ökosystem stammt und das Projekt einen Controller, ein Support-Modell und vorhersagbare native Funktionen schätzt. AES67 in ein sauberes Dante-System einzuführen, kann Takt-, Multicast- und Testaufwand mitbringen, den das Projekt nicht braucht.

Eine hybride Installation ergibt Sinn, wenn eine Anlage eine Dante-Infrastruktur mit einem RAVENNA-System, einem ST-2110-30-Produktionskern, einem Drittanbieter-Prozessor oder einer standardbasierten Aufnahme- oder Monitoring-Plattform verbinden muss. Auch während einer Migration ergibt sie Sinn, wenn ein Standort ein neues Teilsystem einführen will, ohne das bestehende Dante-Netzwerk zu ersetzen.

Die praktische Designfrage lautet nicht abstrakt „rein oder hybrid“, sondern: Welche Flows müssen die Grenze überschreiten und welche Garantie benötigt jeder Flow? Wenige risikoarme Monitor-Streams tolerieren vielleicht eine einfache Bridge. Ein Live-Broadcast-Pfad kann redundante Netzwerke, deterministisches Timing, Monitoring und ein getestetes Ausfallverfahren erfordern.

Auswahl-Checkliste und Missverständnisse

Beginnen Sie die Checkliste mit den Stream-Anforderungen: Richtung, Abtastrate, Paketzeit, Kanalzahl, Multicast oder Unicast sowie das erwartete Wiederanlaufverhalten. Verifizieren Sie dann Dante-Modell, Firmware, Lizenz, Interoperabilitätsmodus, PTP-Konfiguration, Redundanzunterstützung und Verwaltungssichtbarkeit. Testen Sie das konkrete Gerätepaar, nicht nur die Marketing-Kategorie.

Ein verbreitetes Missverständnis ist, dass AES67-Unterstützung ein Dante-Gerät generisch macht. In der Praxis bleibt das native Dante-Verhalten der Kern des Produkterlebnisses. Ein weiteres Missverständnis ist, dass der AES67-Modus immer kostenlos oder über alle Modelle hinweg identisch sei. Lizenzierung, Hardware, Firmware und Produktklasse können die Verfügbarkeit alle beeinflussen.

Ein drittes Missverständnis ist, dass Interoperabilität nur ein technisches Detail sei. Sie verändert Beschaffung, Betrieb, Support und Schulung. Das beste hybride Design gibt jedem Ökosystem eine klare Rolle und schafft eine schmale, dokumentierte Grenze mit messbaren Abnahmekriterien.

• Bestätigen Sie das genaue Dante-Modell und die Firmware-Version.
• Prüfen Sie AES67-Richtung, Kanalzahl und Paketformat.
• Dokumentieren Sie die PTP- und Taktgrenze.
• Entscheiden Sie, wie Multicast, Redundanz und Monitoring funktionieren sollen.
• Testen Sie das Wiederanlaufverhalten, bevor das System abgenommen wird.