O que é AES67 – e por que isso importa?

O Audio-over-IP (AoIP) transformou os fluxos de trabalho de áudio profissionais, mas durante anos o ecossistema foi fragmentado. Cada fabricante – Dante, RAVENNA, Livewire, Q-LAN – usou protocolos proprietários que não podiam falar entre si. Em 2013, a Audio Engineering Society publicou o AES67, um padrão de interoperabilidade aberta que define um conjunto comum de protocolos de rede para que dispositivos de diferentes fornecedores possam trocar áudio de alta qualidade por redes IP padrão. O AES67 não substitui esses sistemas proprietários; ele atua como uma "camada de ligação" que permite a coexistir e interoperar sem que cada dispositivo de suporte a uma única plataforma fechada.

A AES67 é agora amplamente adotada em estúdios de transmissão, som ao vivo, gravação, AV corporativo e até mesmo em algumas aplicações de som instaladas. É a base para outros padrões da AoIP, como o SMPTE ST 2110-30, e contribui para o impulso mais amplo para a produção de todos os IP. Compreender a arquitetura e os protocolos da AES67 não é apenas um exercício acadêmico – afeta diretamente sua capacidade de projetar, solucionar problemas e escalar uma rede de áudio moderna.

Componentes Principais da Arquitetura AES67

Uma rede AES67 é construída sobre quatro pilares essenciais: infraestrutura de rede, sincronização, transporte de mídia e descoberta. Cada componente depende de padrões bem estabelecidos da Força-Tarefa de Engenharia da Internet (IETF), que mantém o sistema confiável e o diagnóstico de fornecedores.

1. Infra-estrutura de rede

O AES67 é executado em Ethernet padrão, mas como carrega áudio isocrônico em tempo real, a rede deve atender a certos requisitos mínimos. IGMP bisbilhotando gerir eficazmente os grupos multicast, DiffServ QoS (Ponto de Código de Serviços Diferenciados) para priorizar pacotes de áudio, e Isolamento VLAN Para separar o controle e o tráfego de mídia. Enquanto 1 Gbps é típico, as plantas de transmissão em grande escala podem usar 10 Gbps ou mais. As molduras Jumbo (até 9000 bytes) são opcionais, mas recomendam reduzir a sobrecarga de pacotes.

Para uma operação confiável, os engenheiros de rede devem permitir filas de prioridades estritas (geralmente COS 4 ou 5 para PTP, COS 3 para RTP áudio) e garantir o encaminhamento de baixa latência. Os interruptores não devem introduzir mais do que alguns microssegundos de jitter, porque a sincronização PTP do AES67 tolera apenas pequenas variações de tempo.

2. Sincronização – Precisão Protocolo de Tempo (PTP)

Todos os dispositivos AES67 devem ser sincronizados com um relógio comum. O padrão manda IEEE 1588-2008 Precision Time Protocol (muitas vezes chamado PTPv2) usando o Perfil AES67 Ao contrário do PTP genérico, o perfil AES67 especifica um número de domínio padrão (domínio 0) e usa mensagens de relógio de dois passos com multicast. O relógio de grande dimensão é tipicamente um servidor PTP dedicado, mas qualquer dispositivo na rede – um microfone, um console de mistura ou uma ponte – pode se tornar o grande mestre se tiver uma fonte de relógio estável.

A Melhor algoritmo de relógio mestre (BMCA) seleciona automaticamente o relógio mais preciso, minimizando a configuração humana. Na prática, os radiodifusores normalmente bloqueiam todos os domínios PTP para uma referência GPS ou GNSS, alcançando a sincronização sub-microssegundo em grandes instalações. Sem esta precisão, os buffers de áudio falhariam ou cairiam.

3. Transporte de mídia – Protocolo de Transporte em Tempo Real (RTP)

As amostras de áudio são encapsuladas em pacotes RTP e transmitidas sobre UDP. AES67 suporta taxas de amostragem comuns: 44,1, 48 e 96 kHz, com profundidades de bits de 16 ou 24 bits (e ponto flutuante de 32 bits para uso intra-studio). Canais por fluxo podem variar de 1 a 8 (mas 4 é típico para interoperabilidade com outras normas como SMPTE ST 2110-30).

RTP formato de carga útil é L16 ou L24 para PCM linear não comprimido. AES67 também permite codificação de μ-lei para compatibilidade com sistemas de telecomunicações antigos, embora isso raramente é usado em áudio profissional. Packets são enviados como fluxos UDP multicast para um endereço de grupo; receptores se inscrevem via IGMP. RTP Protocolo de Controlo (RTCP) é usado para estatísticas fora da banda, mas não para recuperação de relógio – que é manipulado inteiramente pelo PTP.

A latência no AES67 é configurável. O padrão recomendado é de 1 ms (permitindo cerca de 48 amostras por pacote em 48 kHz), mas alguns equipamentos suportam 0,125 ms para monitoramento de latência ultra-baixa ou 4 ms para conexões menos críticas sobre redes congestionadas.

4. Descoberta e Registro

Os dispositivos precisam saber quais fluxos estão disponíveis na rede. Protocolo de Anúncio de Sessão (SAP), que transmite periodicamente descrições de fluxo (formato SDP) para um endereço multicast bem conhecido (224.2.127.254). SAP é simples e leve, mas pode ser conversado em grandes redes.

Outros métodos de descoberta coexistem com AES67: RTSP (Real Time Streaming Protocol) pode ser usado para controle de sessão, e extensões mais recentes como mDNS/DNS-SD O ponto chave é que o próprio AES67 não define um protocolo de descoberta – ele só ordena que os fluxos possam ser descritos usando um arquivo Session Description Protocol (SDP). Os fabricantes são livres de implementar qualquer mecanismo de descoberta que transmita informações sobre o SDP, desde que um dispositivo de terceiros possa analisá-lo.

Protocolos-chave em detalhe

Enquanto os quatro componentes principais constituem a arquitetura, vários protocolos subjacentes merecem uma análise mais atenta. Entender como eles se interligam é o que separa uma implantação funcional do AES67 de uma implementação problemática.

PTP (Protocolo de Tempo de Precisão) – o Batimento Cardíaco

O PTP funciona trocando mensagens cronometradas entre o grande mestre e todos os relógios escravos. O perfil AES67 usa a operação de dois passos: o grande mestre envia uma mensagem Sync, depois uma mensagem de Seguimento Up que contém o tempo exato de partida. Os escravos usam isso para calcular offset e ajustar seus próprios relógios através de um algoritmo servo.

Na maioria dos switches gerenciados, as mensagens PTP devem ser dadas a maior prioridade e nunca ser adiadas pelo processamento de armazenamento e saída. Relógios de limite ou relógios transparentes (TC) nos switches podem compensar o atraso da ponte, mas em pequenas redes uma abordagem de dois passos sem TC é suficiente. O padrão requer que os dispositivos finais bloqueiem dentro de 2 segundos da inicialização e mantenham a deriva abaixo de 1 microsegundo em um intervalo de 1 segundo — estanque, mas alcançável com bom design.

RTP (Protocolo de Transporte em Tempo Real) – Transportador de Carga

Os pacotes RTP carregam um cabeçalho contendo número de sequência, timestamp e SSRC (identificador de fonte de sincronização). O perfil AES67 especifica um tempo máximo de pacote de 4 ms, com 1 ms preferido. Como o RTP passa por cima do UDP, não há retransmissão; a perda de pacote deve ser tratada a montante (por exemplo, via fluxos redundantes ou FEC, embora o AES67 não exija FEC).

Uma armadilha comum: os tempos de pacote descompassos entre remetente e receptor podem causar desistências de áudio. Configure sempre ambas as extremidades para o mesmo parâmetro "ptime" no arquivo SDP. Verifique também que o caminho da rede não excede o tempo de vida RTP (TTL); AES67 recomenda um TTL de pelo menos 10 para pequenas redes.

SIP (Protocolo de Iniciação da Sessão) – uma Sobreposição Útil

AES67 menciona o SIP como um método possível para gerenciamento de sessão e descoberta de fluxo, mas raramente é a abordagem primária. Na prática, a maioria dos dispositivos AES67 dependem da SAP ou interfaces web proprietárias. O SIP é mais comum em intercomunicadores orientados para as telecomunicações como VoIP ou SIP que se integram com pontes AES67.

Benefícios da AES67 no Mundo Real

O principal benefício é o interoperabilidade sem bloqueio Uma instalação de transmissão usando RAVENNA para links estúdio-transmissor pode aceitar microfones equipados com Dante; uma consola de som ao vivo pode puxar um fluxo de um Q-SYS DSP. A AES67 atua como um “tradutor” universal que elimina a necessidade de hardware de gateway dedicado em muitos casos.

Outras vantagens incluem:

  • Escalabilidade: Como o AES67 usa multicast IP padrão, você pode adicionar centenas de fluxos, desde que seus switches possam lidar com a contagem de grupos multicast e largura de banda. Não há taxa de licenciamento por canal.
  • Custo-eficácia: Nenhum hardware de rede proprietário necessário – os interruptores de boa qualidade fora da prateleira funcionam quando configurados corretamente.
  • À prova de futuro: Como o SMPTE ST 2110 se torna a norma em transmissão, o AES67 (que é idêntico à parte de áudio do ST 2110-30) já está lá. Um estúdio que constrói uma rede AES67 hoje pode migrar para o ST 2110 completo de vídeo-over-IP mais tarde com mudanças mínimas.
  • Confiabilidade: O crocing baseado em PTP elimina os problemas de deriva e nervosismo que assolam redes antigas de isocrônicos. A tolerância da AES67 para perda de pacotes (até 1% sem falha crítica em sistemas bem abobadados) adiciona resiliência.

Guia de Implementação – Construir a sua primeira rede AES67

A implantação da AES67 requer mais do que apenas a ligação de dispositivos. Siga esta abordagem estruturada para evitar dores de cabeça comuns.

Passo 1: Verificar a Compatibilidade do Dispositivo

Nem todos os dispositivos que afirmam “AES67” são totalmente compatíveis. Verifique a lista de interoperabilidade AES67 (mantida pela Media Networking Alliance). Se você misturar Dante e RAVENNA, por exemplo, garanta que o módulo Dante suporta o modo opcional AES67 (disponível em muitos modelos mais novos). Algumas engrenagens antigas requerem uma atualização de firmware.

Passo 2: Desenhe a Topologia da Rede

Usar um topologia da estrela com um interruptor de núcleo e interruptores de borda, ou uma folha de coluna para plantas grandes. Habilite o IGMP bisbilhotando e Querier em cada VLAN que carrega áudio. Controle separado e tráfego de áudio: VLANs dedicados para PTP e fluxo multicast reduzem o risco de má configuração.

Atribuir endereços IP estáticos a dispositivos críticos (relógio grandmaster, unidades fixas de I/O). O DHCP é aceitável para os terminais se a locação for longa, mas evite endereços dinâmicos para grandes mestres PTP.

Passo 3: Configurar o PTP

  • Designar um grande mestre primário (por exemplo, um servidor PTP bloqueado por GPS).
  • Garantir que todos os dispositivos usam o perfil AES67 (IEEE 1588-2008, 2 passos, domínio padrão 0, multicast).
  • Defina todos os interruptores para o modo de relógio transparente (se for suportado) ou o modo de relógio limite. No mínimo, eles não devem filtrar mensagens PTP; certifique-se de que o multicast Ethernet PTP é permitido (endereço MAC 01-1B-19-00-00-00).
  • Monitorar o deslocamento do PTP em cada dispositivo – ele deve ser < 1 μs. Se exceder 10 μs, existe um problema de tempo de rede (diminuição do atraso, sobrecarga de CPU ou jitter de cabeamento pobre).

Passo 4: Configurar os Fluxos

Use a interface Web do dispositivo ou o software de controle para criar um fluxo de transmissor. Capture o arquivo SDP (frequentemente para download como um arquivo .sdp). No receptor, importe o SDP ou use a descoberta automática (SAP/mDNS). Verifique se o fluxo aparece na rede: você pode usar o filtro de tela para ver os pacotes. Verifique o SSRC – SSRC duplicados entre fluxos pode causar confusão nos receptores que não o manuseiam graciosamente.

Passo 5: Teste e Valide

  • Meça a latência entre transmissor e receptor usando um tom e osciloscópio, ou uma ferramenta de analisador RTP. O padrão de 1 ms da AES67 deve ser alcançado por meio de um simples switch.
  • Teste a resiliência da perda de pacotes desligando um cabo brevemente; o áudio não deve falhar para pacotes perdidos de 1-2 ms de duração. Se isso acontecer, aumente ligeiramente o tamanho do buffer (até 4 ms).
  • Verifique se o bloqueio PTP é mantido quando você adiciona vários fluxos. Um erro comum é sobrecarregar a CPU com mensagens PTP em uma porta mal configurada; use o interruptor QoS para priorizar o PTP.

Passo 6: Documente sua configuração

Grave o papel IP, PTP de cada dispositivo, fluxo SDP e configuração da porta de comutação. Isto é inestimável quando um componente falha e precisa de substituição. Sem documentação, reconstruir uma grande rede AES67 do zero é quase impossível.

Pistácios comuns – e Como Evitá-los

  • Conflitos de contagem de PTP: Executar vários domínios de PTP na mesma rede (por exemplo, sistema de filmes usando o domínio 0 enquanto uma consola de som ao vivo usa o domínio 1) pode causar confusão. Atenha-se a um único domínio ou isole com VLANs.
  • O IGMP a bisbilhotar não está activo: Sem ele, o áudio multicast inunda cada porta de comutação, causando perda de pacotes e carga desnecessária. Ative sempre IGMP em cada VLAN.
  • QoS mal configurado: Se o PTP for atrasado atrás de uma explosão de tráfego FTP, a sincronização é deriva. Use filas de prioridade estritas (DSCP 46 para PTP, DSCP 34 ou 36 para áudio RTP).
  • Desvio da imagem Jumbo: Se o interruptor suporta quadros jumbo mas o remetente não, você pode obter fragmentação. Mantenha todos os dispositivos no mesmo MTU (1500 ou 9000).
  • Ignorando o jitter de rede: Mesmo com PTP perfeito, buffers de jitter RTP devem ser configurados para absorver jitter de rede. Use "ptime" consistente com o jitter pior caso da sua rede.

Comparação com outras normas AOIP

AES67 não é um produto, é uma norma de ligação. Dante domina o mercado AV instalado e suporta AES67 como um modo secundário. RAVENA é popular em transmissão e já usa AES67 como seu transporte de áudio nativo. Fio ao vivo. (de Wheatstone) é construída na AES67. Q-LAN (QSC) também suporta AES67.

A diferença chave: em um ambiente multivendor, AES67 garante que todos eles falam a mesma língua. Quando você precisa da menor latência (sub-0,25 ms), sistemas proprietários ainda têm uma borda, mas para 99% do uso profissional, AES67 1 ms é mais do que adequado.

O Futuro da AES67

A Audio Engineering Society continua a evoluir o padrão. AES67-2022 adicionou suporte para o flutuador de 32 bits, clarificou o manuseio de fluxo redundante e atualizou o perfil PTP para se alinhar com o IEEE 1588-2019. Aliança de Redes de Mídia Como o SMPTE ST 2110 expande além da transmissão em eventos ao vivo e casas de adoração, o AES67 continuará sendo a espinha dorsal do áudio. Para qualquer engenheiro que tenha projetado um sistema de áudio em rede hoje, o AES67 não é apenas um bom-ter – é a aposta mais segura para compatibilidade de longo prazo.

Para mergulhar mais fundo, consulte o oficial Norma AES67 (AES67-2018/R2023), RTP RFC (RFC 3550), e Norma IEEE 1588-2008. Guias práticos de Audiato e RAVENA Oferece estudos de caso de implantação no mundo real. Com uma sólida compreensão da arquitetura e protocolos da AES67, você pode projetar uma rede de áudio que seja de alto desempenho e realmente aberta.