Comments to date on DRAFT AES70-21-xxxx AES standard for audio applications of networks - Open Control Architecture - Part 21: Using AES70 to manage AES67 and SMPTE ST 2110-30 media transport
, published 2024-08-25 for comment.
Comment received from A. Kuzub, 2024-09-09
I am writing to express some comments and recommendations about the ongoing development of the AES70-21 standard. After a review of the draft (AES70-21-xxxx-CFC), I would like to address two main points that I believe are critical for the robustness, clarity, and future-proofing of the standard.
1. It is striking to note that within the scope of the AES70-21 standard, there appears to be a lack of a normative approach to ST 2022-7 redundancy. Such redundancy is key to ensuring high availability and reliability of media transport, especially within the context of the SMPTE ST 2110-30 implementation. It is largely expected for devices to support dual-stream redundancy. It would be beneficial for the standard to reflect this by incorporating it in a more prescriptive section of the document rather than as an informative note (Sections 10.5.2. "Aes67EndpointAdaptationData field values for specific use cases" and 11. "Related protocol support"). This will aid in compliance and interoperability among devices.
2. While the AES70-21 standard aims to address the management of AES67 and SMPTE ST 2110-30 media transport, the convergence of these two within a single connection standard may warrant reconsideration. This amalgamation presents a potential oversight with respect to maintaining clear and distinct guidelines for the development and implementation processes of each protocol standard.
The specification as outlined does indeed address Aes67EndpointIPParameters, providing a structure for handling IP parameters associated with AES67 endpoints, as indicated in the content provided. However, for full and explicit SMPTE ST 2110-30 integration, separate parameter sets for primary and secondary streams are essential. The standard would benefit from a clear differentiation, possibly as Smpte211030PrimaryEndpointIPParameters and Smpte211030SecondaryEndpointIPParameters, respectively, to specifically cater to the redundancy requirements intrinsic to ST 2110-30.
While Annex C details the related Session Description Protocol (SDP) elements, it lacks a comprehensive example that fully illustrates a redundant ST 2110 stream setup. Including a demonstrative example of a complete redundant ST 2110 stream within the informative Annex C would not only be beneficial but also serve as a valuable practical guide for implementers to better understand the operational intricacies of such systems.
Addressing these gaps would significantly aid in clarity and could improve the implementation process for those developing and managing systems based on the AES67 and SMPTE ST 2110-30 standards
3. Not a hill I would die on: but, in an endeavor to enhance clarity and promote a systematic approach within the Open Control Architecture standards, it might be prudent to consider revising the numbering schema for greater specificity and avoidance of potential ambiguity. Employing designations such as AES70-67 and AES70-30 could serve to distinctly categorize the standards associated explicitly with AES67 and SMPTE ST 2110-30 media transport protocols. This tailored nomenclature would not only offer immediate insight into the scope and applicability of each standard but would also simplify future maintenance, allowing for a more streamlined process when updating or revising these standards. The proposed division into AES70-67 and AES70-30 would likely be beneficial in mitigating the risk of conflating guidelines between the two protocols and provide clear pathways for implementation by manufacturers and other stakeholders.
------------
The evolutionary paths and potential revisions for AES67 and ST 2110 might differ significantly as each responds to unique sets of requirements and use cases over time.
Considering these nuances, it might be more pragmatic to envision a bifurcated structure, creating two separate parts within the standard – one addressing AES67 and the other dealing exclusively with ST 2110.
This separation could afford more clarity and ease of maintenance, allowing for specialization in implementation where a user may be inclined to adopt one protocol independent of the other.
While I understand that the development of standards is a complex and nuanced process, accommodating a multitude of stakeholders, I believe these recommendations would provide clearer guidelines and promote a more forward-looking approach to redundancy and protocol specialization within the standard.
Thank you for taking the time to consider these points. Your diligent work on these standards is invaluable to our industry, and I eagerly anticipate further development in these areas.
Kind regards,
Anthony
Anthony P. Kuzub (he / him)
CBC - Technology and Infrastructure
Senior Systems Designer / Project Lead
Production Systems, Engineering Solutions
