Comments to date on DRAFT REVISED AES67-xxxx AES standard for audio applications of networks - High-performance streaming audio-over-IP interoperability
,
published 2015-07-27 for comment.
The comment period has closed. There are no unresolved comments.
We found some details of SDP examples included in AES67 document that look
like mistakes.
* According to the RFC 7273 grammar in section 4.8, PTP domain number should include "domain-nmbr=" string prefix before the actual number. The string does not appear in examples in RFC 7273 and AES67 (8.5.1, 8.5.2) documents. We have:
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
but according to the grammar, should be:
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:domain-nmbr=0
* Sections 8.5.1 and 8.5.2. The "t" line missing the second zero parameter. Should be "t=0 0".
* In section 8.5.2, the unicast connection string includes /TTL. TTL is required for multicast, but should not be specified for a unicast address.
Kind regards,
Maciej Szlapka, Telos Alliance
Maciej,
Thanks for your careful review of the draft AES67 revision. I have verified the inconsistency you have found in RFC 7273 between normative ABNF specification and the examples in Figures 6, 7 and 8. Although there is potential for error due to this inconsistency, implementers who read the RFC carefully should appreciate that the ABNF specification takes precedence over what's demonstrated in the examples. As one of the authors of RFC 7273, I will work to get this inconsistency corrected.
With regards to the AES67, the domain specification will be corrected in sections 8.5.1 and 8.5.2 to use the "domain-nmbr=" notation.
The t= specification as defined in section 5.9 of RFC 4566 does require two integer parameters. The examples in 8.5.1 and 8.5.2 will be corrected to conform to this requirement by adding a second "0" parameter.
The ABNF in section 9 of RFC 4566 does specify different syntax for unicast and multicast IPv4 addresses and, as you note, the unicast syntax does not feature the TTL specification. This will be removed from the example in 8.5.2.
Since all of these changes affect informative examples in the draft, they will be handled as editorial corrections.
Please reply by the end of the comment period if this reply is not acceptable to you. You may also ask us to consider your comments again for the next revision of the document. You may also appeal our decision to the Standards Secretariat.
Kevin Gross - AVA Networks
Vice chair AESSC working group SC-02-12 on Audio Applications of Networks
I would like to make comment regarding the Draft Revision of the AES67 standard.
By nature of achieving a successful result in establishing this standard, which explicitly uses the term “interopobility”, I believe there is a current shortcoming in that a necessary component of interopobility is the need for auto Discovery.
Discovery provides an efficient means of identifying other audio devices and sources to facilitate interopobility. Without discovery, it is impossible to interoperate. Alternate methods to Discovery to establish interoperability are believed to be very inefficient, not practical and not necessarily successful.
Discovery systems have been mentioned in Annex E, with references to 4 possible methods of discovery, E.1, E.2, E.3 and E.4
Three of these are proprietary methods developed by commercial product manufacturers. Only one of these methods referred is a “non proprietary” and published standard referred in your document at E.2 as SAP. SAP version 2 as defined in the standard RFC 2974 is a mature protocol published in 2004. It is not deemed appropriate in the evolution of this standard to support commercially proprietary methods of discovery, over non proprietary methods.
It is therefore recommended that SAP version 2 is mandated as part of this revision to AES67 to achieve true Audio over IP interopobility.
Proposed wording for the draft revision, as follows;
"9 Discovery Discovery is the network service which allows participants to build a list of the other participants or sessions available on the network. Such a list can be presented to users to assist with connection management. Connection management requires a SIP URI (see 10.1) or SDP description (see 8). These may be delivered through SAP.
Use of SAP, or a similar mechanism to distribute SDP descriptions to potential receivers, enables a simplified connection management for multicast streaming (see 10.2).
SAP version 2 as defined in RFC 2974 is to be used. SDP descriptions as defined in 8 should be carried in the payload of SAP messages. Multicast sessions should be announced using destination address as specified in RFC 2974 clause 3; globally scoped multicast sessions are announced using 224.2.127.254 destination address and administratively scoped multicast sessions are announced using the highest address in their scope.
With the above amendment, Annex E in total can be removed from the draft revision.
The Australian Broadcasting Corporation has an active interest in the evolution of AoIP and AES67. As Australia’s largest broadcaster, the potential success of AoIP will bring significant opportunities and efficiencies to our operation. We are highly appreciative of the work that has been done in developing this standard and we are keen to see it continue to evolve.
Kind Regards,
Michael Blackburn Broadcast Solutions Architect
Australian Broadcasting Corporation
Michael,
Thank you for your comments. The topic of discovery was discussed at length during development of AES67-2013. There was no motion to reopen this decision during work on this revision. In our original discussion, the group appreciated that there are limitations to all of the proposed discovery mechanisms. The identified limitations of SAP lie in its "experimental" designation by the IETF.
The final decision to exclude discovery as a required element of AES67 recognized that there were no existing discovery solutions that clearly met the requirements for the project and that there are numerous examples of interoperable communications systems that are fully functional without the benefit of an integral discovery capability: the telephone system, internet email and the worldwide web.
Please reply by the end of the comment period if this reply is not acceptable to you. You may also ask us to consider your comments again for the next revision of the document. You may also appeal our decision to the Standards Secretariat.
Kevin Gross - AVA Networks
Vice chair AESSC working group SC-02-12 on Audio Applications of Networks
RE: reply to my comment on Draft Revised “AES standard for audio applications of networks – High-performance audio-over-IP interoperability”
I received a reply to my comment (24 August) on the Draft Revised AES standard (AES67) on 28 August.
The replier wrote “… there are numerous examples of interoperable communications systems that are fully functional without the benefit of an integral discovery capability: the telephone system, internet email and the worldwide web.”
I would like to point out that typical AoIP solutions provide multi channel audio connectivity, in fact 64 channels of bi-directional audio, is very common. It is this multi-channel audio capability that provides commercially attractive opportunities, of which is a fantastic selling point for AoIP.
However, without Discovery as a feature of AES67, the establishment of interopobility between two different AoIP protocols will become extremely tedious, potentially complex and very time consuming. Not only will IP addresses need to be identified, but also channel identifiers, all 128 of them with one version of a typical AoIP solution. Quite possibly this manual configuration may have to be repeated for both ends of the interconnection, doubling the configuration work required. There may be other nuances also requiring configuration for each combination of AoIP protocols, that at this stage are unknown.
In reply, I must say I am quite surprised that comparing a ”current” technology standard to the quite obvious and cumbersome plain old telephone systems, which did require a significant amount of manual configuration to get anything to work, is hardly a current day acceptable approach. Current technologies in everyday use by you, i.e. our computer systems, our mobile devices, typically all include Discovery. To be promoting a new standard without Discovery is a step backwards in time. The result of this will limit the success or even possibly promote the failure of AES67.
The fact that Wheatnet, Livewire and Audinate have their own and disparate Discovery protocols, already clearly identifies the importance of Discovery as a necessary feature that should be mandated within a revision of AES67.
As per my original comment, I believe a mandated Discovery protocol is absolutely necessary as a practical approach to achieve Interopobility. If this is not done, then every developer of AoIP solutions will, as they have already done, develop or adopt their own methods of Discovery with their own products. And most importantly, the Discovery protocol, should be an existing non proprietary industry standard. SAP is one such protocol that is functional and serves this purpose as adopted by Audinate. As an extensive user of Audinate solutions, I can vouch that it perfectly serves the purpose.
In this regard, I do appeal the decision in rejection of my comment as part of this revision. I therefore, again request that Discovery and SAP as one current non-proprietary acceptable method of Discovery, is mandated as at least one protocol to be included as a revision of the AES67 standard.
Should this be further rejected, then I request that this is considered with high importance for the next revision.
Thank you for your further consideration, I hope that this input will contribute positively to the ongoing evolution and success of AES67.
Kind Regards
Michael Blackburn Broadcast Solutions Architect
Australian Broadcasting Corporation
Dear Mr. Blackburn,
In re-reading your second comment, I noticed the word 'appeal' in paragraph 8. It occurred to me that you may be referring to the appeals procedure in our due-process rules (clause 9.1.3) and operating procedures (clause 6).
The technical content of the standard is properly a matter for the AESSC working group responsible, in this case SC-02-12 "Working Group on Audio Applications of Networks". Kevin Gross is vice-chair of SC-02-12, and was the principal author of AES67, originally published in September 2013.
I believe that Kevin Gross will be in touch with you concerning the specific technical point you raised, and the group's intention to consider it in the future.
My role is to ensure that our published procedures are followed correctly so that our published standards represent due process. In this case I can confirm that the draft revision for AES67-2013 has shown consensus in the working group, and that the progress stages, including the document's scope, have been openly and continuously published on the AES web site since the introduction of the parent development project, AES-X192, back in 2010. The specific issue of discovery is discussed in annex E, indicating that no consensus has yet been reached on a single discovery technique for standardization. This does not prevent a discovery technique being standardized in a future revision of this standard, or in a separate standard intended to complement AES67 and, perhaps, other relevant networking standards for audio.
Please note that an AES standard must be reviewed every five years, but may be revised at any time. You should note that this latest revision of AES67 is only 2 years after the initial publication.
I hope this helps to clarify the procedure.
sincerely,
Mark Yonge
AES Standards Manager
Mr. Blackburn,
Thank you for your follow-up comments. I believe there is a good appreciation within the responsible AES standards groups of the value of discovery for AES67 applications. There have been presentations to SC-02-12 outlining requirements for discovery and name services which would fulfill the needs of AES67 and audio system control protocols such as AES64 and the AES-X210 work to standardize the OCA protocol. We have hopes that a separate initiative will produce usable results. We do not anticipate any change would be required to AES67 to support a separate discovery and name service standard.
It is a valid point that configuring a large number of AES67 streams on a network is a complex undertaking. Other protocols and systems beyond those outlined in the AES67 standard are generally required to manage large networks. Mandatory discovery would be helpful to these management systems but would not be sufficient to produce the level of usability requested. Dante, for instance, includes Bonjour for discovery but also uses a custom "API" protocol and Dante Controller software to complete network management tasks.
AES67 was carefully scoped to produce usable network audio interoperability which can be built upon by manufacturers and users. There was no motion during the revision process to expand the scope of AES67 to comprehensively address network management.
The public comment period for this AES67 revision is closing presently. I believe I have addressed your comments and assure you that we will revisit the discovery question in future revisions. I encourage you to participate in this future work if you are able. You do still have the option to appeal to the Standards Secretariat and I believe Mark Yonge has explained separately how that process works and its limitations.
Kevin Gross - AVA Networks
Vice chair AESSC working group SC-02-12 on Audio Applications of Networks
