In questa terza parte parleremo di Interoperability, AES67, ST2110, ST2022-7 e ridondanza.
Per comprendere al meglio questi nuovi aspetti consigliamo la lettura delle precedenti parti, che possono essere “recuperate” qui: (Parte 1 – Parte 2)
Dante, Ravenna, Livewire, Q-Lan sono tutti approcci AoIP, ovvero tutti al layer3, ma “grazie” ad alcune differenze di implementazione non si possono “parlare” o “suonare” l’un con l’altra o, per dirlo all’inglese “there’s no interoperability”.
Sembra di essere tornati al tempo in cui io ero “già” su Mac e per i miei testi utilizzavo Pages mentre gli altri erano “ancora” su Windows e Word. Se io davo loro un mio file .pages loro non sapevano che farsene, anche se in fin dei conti il contenuto di quel file altro non era che caratteri ASCII, parole, un po’ di impaginazione, qualche scelta di font, tutte cose che anche Word era assolutamente in grado di gestire!
Fortunatamente esisteva la possibilità di esportare il mio file in .txt o .rtf, ovvero in un formato STANDARD che potesse essere gestito da qualsiasi computer, sistema operativo e software di elaborazione testi.
Ecco, questa è una buona similitudine: AES67 è un po’ come il .txt (o.rtf) per gli approcci AoIP (Layer3!) e grazie (stavolta non in senso ironico) ad AES67 è garantita l’interoperabilità dei formati ad esso compatibili, o compliant, se vogliamo dirlo in maniera international.
AES67 è stato introdotto per la prima volta nel 2013, ha subito delle revisioni ed è oggi alla versione 2018.
Lo standard AES67 definisce diversi parametri che debbono essere rispettati dai vari vendors per essere “compliant” ad esso, quali la versione del PTP (che è la v.2), il formato degli Ethernet frames, il payload (deve essere presente almeno la versione con 48 sample), stabilisce il numero massimo di canali per stream (pari a 8 @48kHz) e la sintassi del file SDP (Service description protocol) che deve accompagnare ogni stream generato, ovvero quasi tutto ciò che serve.
Perché quasi?
Perché l’AES non ha voluto o potuto imporre il metodo di DISCOVERY necessario a reperire la lista degli stream presenti in un determinato network e ha lasciato ad ogni vendor la possibilità di effettuare tale operazione nella maniera che preferisce.
Ma cos’è il DISCOVERY e come funziona?
Cerchiamo di spiegarlo in maniera semplice e rapida. Io sono un utente interessato ad ascoltare uno stream che è (o dovrebbe essere) disponibile in rete. Chi o che cosa mi fornisce la lista degli stream? Chi o che cosa mi fa conoscere i parametri necessari per avviarne l’ascolto?
Non c’è un gestore della rete, non c’è una sorta di server che faccia queste operazioni, a chi mi devo rivolgere?
E’ DOVERE di chi genera gli stream pubblicizzare la loro esistenza, in primis e fornire tutti dettagli necessari per effettuare il “subscribe”, in secundis.
Siccome non esiste un software che memorizza tutti gli indirizzi IP dei vari stream presenti che via via popolano la rete, men che meno sono i vari Ethernet Switches che se ne possono occupare, occorre che periodicamente e continuamente queste informazioni vengano “messe in circolo” da ogni apparato generatore di stream.
Sempre con il metodo delle analogie è come se ogni Stage Rack (giusto per fare un esempio) ogni 5 secondi prendesse la parola e urlasse a tutti “ho disponibile uno stream da 48 canali a 48kHz riportante i primi 48 canali della channel list, chi è interessato lo può trovare all’indirizzo ip 239.69.1.1 e dallo stesso indirizzo può effettuare il download del SDP file con tutti i dettegli per effettuare la sottoscrizione!”
Ecco, la maniera con il quale quello stage rack “urla” quelle informazioni è il metodo di DISCOVERY.
Siccome Dante, da tempo memorabile, utilizza il protocollo SAP mentre Ravenna utilizza RTSP (meglio conosciuto come Bonjour), se l’AES avesse deciso uno dei due o addirittura un terzo metodo, avrebbe di fatto obbligato i vari vendor a profonde revisioni dei propri sistemi, per cui ha deciso, in maniera “ponziopilatesca”, di non decidere sul metodo di discovery, ma specificare solo i parametri audio.
I vari vendors, nella implementazione dell’AES67, hanno quindi la possibilità di scegliere. Quelli più vispi di fatto decidono di essere bilingue, ovvero permettono l’utilizzo sia di SAP (Dante style) che RTSP (Ravenna style) sia per la pubblicizzazione (quando si generano stream e li si immettono in rete) che per il discovery (quando si sottoscrivono stream già in rete).
E’ così che finalmente uno stream Dante in versione AES67 generato da uno stage rack Yamaha può tranquillamente essere sottoscritto da una console Lawo che è nativa Ravenna, da un amplificatore QSC (che è nativo Q-Lan) e da consoles broadcast Wheatstone (nativa Wheatnet) e AXIA (nativa Livewire).
E’ tutto molto bello e funziona anche bene fino a che… non vogliamo utilizzare sistemi ridondanti.
Già, se vogliamo che le connessioni AoIP siano ridondanti entrano in gioco elementi fortemente limitanti che minano la reale interoperabilità.
Ad oggi, infatti, Dante supporta AES67 solo in modalità non ridondante. Se attiviamo la redundancy in apparati Dante (utilizzando Dante Controller) notiamo che la gestione AES67 sparisce.
I motivi politici di tale scelta non li conosciamo, possiamo però supporre che abbiano un fondamento tecnico in quanto lo schema di ridondanza di Dante è totalmente diverso da quello che, ad esempio, utilizza Ravenna e che è lo stesso scelto anche da AES67.
Cerchiamo di capire sia dove stanno le differenze dal punto di vista tecnico sia di capire il perché dei mondi che hanno cercato di aumentare l’interoperabilità hanno poi deciso ben presto di riprendere strade diverse su aspetti così impattanti.
SMPTE, altro organismo internazionale di standard, ha messo a punto il nuovo ST 2110, Professional Media Over Managed IP Networks, che andrà a rimpiazzare via via tutti gli altri standard video a partire da SDI, proprio come i vari approcci AoEthernet o AoIP stanno facendo con i buon vecchi MADI, AES3 etc.
Come rappresentato in figura, il sottoinsieme ST 2110-30 definisce come la parte audio dello stream multimediale debba essere costruito. Tale struttura è di fatto l’AES67.
Possiamo dunque affermare che la parte audio del nuovo standard video over IP è di fatto l’AES67.
SMPTE ha anche definito come debba funzionare la ridondanza mediante lo standard ST2022-7 (vedi figura), ovvero ogni stream main o backup possono viaggiare sia sulla stessa rete che in reti totalmente distinte e DEBBONO avere indirizzi ip distinti, pur avendo lo stesso identico contenuto informativo (Sync, Video, Audio, Dati, Metadati, etc).
Su questo schema si basa dunque AES67 per definire come si possano creare e gestire stream ridondanti mentre Dante ha un approccio completamente diverso: le reti Ethernet Main e Backup sono sempre identiche (formate dagli stessi stream) e distinte e se qualcosa succede alla Main TUTTO passa sulla rete di Backup.
E’ dunque comprensibile che se un sistema swappa tutta la rete (Dante) mentre l’altra swappa uno stream per volta (quelli che ne hanno bisogno – AES67) è ovvio che non possano essere compatibili e… addio interoperabilità ridondante.
Come possono ovviare a queste differenze gli operatori che oggi non vogliano rinunciare né alla interoperabilità né a sistemi ridondanti?
Quando gli approcci non sono compatibili occorre giocoforza effettuare la conversione in maniera esterna alla rete Ethernet affidandosi ad apparati che offrano ridondanza e conversione di formato.
Ed ecco che il protocollo MADI, di cui già più volte si sono svolti troppo prematuramente i “funerali”, resuscita e torna a ricoprire un ruolo importante, anche se diverso da quello che ha ricoperto negli ultimi 20 anni, ovvero è diventato protagonista in fantastici traduttori multilingue.
Lo schema riassunto in figura ben descrive una reale soluzione odierna e non solo per convertire approcci Layer3 (over IP), ma a quel punto qualsiasi formato che possa essere convertito bidirezionalmente da e per il MADI.
E’ presumibile che presto o tardi appaiano sul mercato device in grado di effettuare tali conversioni anche senza l’utilizzo del MADI ed è probabile che io ne sappia di più di quanto possa dirvi oggi…
Nella speranza che questi tre “episodi” possano essere stati di aiuto per la comprensione di argomenti ancora un po’ ostici a noi “audio boys”, vi saluto e vi aspetto in futuro, qui sulle pagine dello “Zio”.
Luca Giaroli
ZioGiorgio Contributor
