Comme pour le ST 2022-6, ST 2110 utilise RTP comme couche de transport. Le transport de chaque essence est défini dans une partie spécifique de la norme : ST 2110-20 pour la vidéo en bande de base, ST 2110-30 pour l’audio, et ST 2110-40 pour le transport des données auxilliaires.

A ma connaissance, dans le contexte considéré par le ST 2110, il n’y a pas de meilleur choix que RTP . D’une part RTP est utilisé massivement et les actifs réseaux le gère parfaitement. D’autre part, cela permet de bénéfécier de fonctionnalités exterieures à la norme - comme par exemple la gestion de la redondance spécifiée dans la norme ST 2022-7.

Cependant, et certainement par soucis de compatibilité avec AES 67, les best practices utilisés jusqu’à présent lors de la définition de protocoles basés sur RTP n’ont pas été respecté. De manière usuelle, la signalisation du contenu d’un flux RTP est contenu dans ce flux : certains paquet RTP sont dotés d’un header qui permet au récepteur de comprendre ce qu’il reçoit et de traiter le flux sans plus d’information.

Dans ST 2110, cette signalisation a été externalisée : les headers RTP ne sont pas auto-suffisant, il est nécessaire d’injecter dans la configuration du récepteur la description du signal qu’il reçoit. Par conséquent, lorsqu’un décodeur reçoit un flux ST 2110, il ne peut rien en faire. De fait, il n’est même pas capable de savoir qu’il reçoit bien du ST-2110. En tant qu’utilisateur, il faut non seulement que je renseigne les informations d’adressage du flux IP, mais aussi que je renseigne la nature du flux dans la configuration. Enfin, le récepteur perd toute autonomie : si le format du flux change, alors il ne peut plus décoder le flux jusqu’à la mise à jour de sa configuration.

Hérité des systèmes de VoIP, puis d’AES 67, la signalisation de la nature des flux est effectuée en SDP "Session Description Protocol". Ce standard est prévu pour être facilement compréhensible par des équipements sans puissance de calcul comme utilisé en téléphonie IP. En contrepartie, le format est peu flexible, difficilement extensible - et nécessite des outils dédiés.

À la différence d’AES 67 qui spécifie les mécanismes d’annonce et de découverte des flux par le biais de SAP (Session Announcement Protocol), SMPTE a décidé de ne pas intégrer les mécanismes d’annonce et de découverte dans le standard.

C’est un choix qui peut se comprendre, mais qui implique qu’une architecture ST 2110 "only" n’est utilisable qu’en labo ou avec un nombre de flux excessivement réduit - sous peine d’en rendre l’exploitation excessivement fastidieuse.

S’il est trop tard pour revenir sur la signalisation au format SDP, il semble nécessaire d’envisager un format structuré pour la signalisation. A cet effet JSON est le candidat le plus logique : utilisé par les API NMOS, les outils nécessaire à son traitement sont déjà présents dans les équipements. Les contraintes qui existaient en 1998 lors de la création du standard SDP n’existent plus depuis longtemps, et la puissance de calcul nécessaire pour traiter des objets de ce type est négligeable.

Une fois le format choisi, il faudrait :

Toute latitude est alors ouverte pour venir enrichir le standard avec des descripteurs qui n’existent pas aujourd’hui, et retrouver la souplesse que l’on peut avoir sur des protocoles comme MPEG-TS.

Il est à mon sens absolument primordial que le flux soit auto-suffisant, et qu’un récepteur puisse avoir la capacité à se configurer sur simple réception des packet RTP, et de fournir un mécanisme capable d’envoyer des informations synchrones avec le flux considéré - qu’elles décrivent le format du flux, ou des métadonnées tierces, comme des informations sur la langue d’un flux audio, l’age légal d’un flux vidéo, ou encore le nom du service associé à ce flux.

A cet effet l’utilisation d’une extension de header RTP est une possibilité : elle est mentionnée dans ST 2110-10, et prévue à cet effet. Il est donc possible de définir une extension de header permettant de transporter sur certains packets des informations au format JSON sur le flux sans casser la compatibilité avec l’existant.

Il semble obligatoire de spécifier un mécanisme au niveau du protocole permettant à minima de

SRTP (Secure Real-time Transport Protocol) pourrait être une réponse à ces interrogations, dans la mesure ou il fourni exactement l’ensemble des outils nécessaires, mais il est possible que les débits considérés ne rendent son utilisation trop consommatrice en ressources de calcul.

Ce point du standard nécessite une bonne dose d’innovation pour permettre de couvrir les trois points clefs de la sécurité, sans pour autant venir complexifier l’utilisation du flux de manière excessive.