Report of the meeting of the SC-02-12 Working Group on Audio Applications of Networks of the SC-02 Subcommittee on Digital Audio held in conjunction with the AES 141st Convention in Berlin, Germany, 2017-05-21.
Attendees:
Axel Holzinger, Stefan Heinzmann, Jeff Berryman, Peter Stevens, Greg Shay, Fredrik Bergholtz, Arne Bonninghaft, Andreas Hildebrand, Nicolas Sturmel, Gints Linis, Umberto Zanghier, Kevin Gross, Junichi Yoshio, Paul Treleaven, Kazuho Ono, Richard Cabot, Mark Yonge, Morten Lave, John Grant - by electronic link
The meeting was convened by chair Morten Lave.
The report of the previous meeting, 2016-10-01, was accepted as written.
The agenda was approved with the addition of new business requested by Gross: "Transport of audio meta data over IP networks".
Projects assigned to this group but not mentioned here had no action requested or required - see www.aes.org/standards/meetings/project-status.cfm for details.
Open Projects:
AES64-R: Review of AES64-2012, AES standard for audio applications of networks - Command, control, and connection management for integrated media
This standard is due for review in 2017, and any revision should be performed before the review date. The capabilities that are particular to the protocol should also be highlighted in the associated informative document, AES-X170B.
Richard Foss provided report on work required and is willing to do the work stated in the report. The report "Working Group Report regarding updates to AES64 standard.pdf" has been uploaded to the SC-02-12 repository.
AES-X170B AES standards report - supplementary information on AES64.
A general discussion followed about when to retire or stabilize a standard. Cabot mentioned that the AES standards organization must judge if maintaining a standard which is not being used widely and which does not seem to have any uptake, will take unnecessary resources away from other work.
In this regards it was mentioned that only two companies have implemented AES64. As part of this discussion it was also stated that both AES64 and AES70 are control protocols and there is no clear scope identifying how AES64 differs in application.
As a result of these discussions we would like to ask the parties interested in AES64 to provide a positioning statement which clarifies the application of AES64. It was noted that AES70 does have such a statement.
The group would then review the statement and seek to conclude whether to either:
a) Continue to maintain AES64 or,
b) Stabilize AES64 or,
c) Retire AES64
AES70-1-R Review of AES70-1-2015: AES standard for audio applications of networks (framework)
AES70-2-R Review of AES70-2-2015: AES standard for audio applications of networks (class structure)
AES70-3-R Review of AES70-3-2015: AES standard for audio applications of networks (TCP/IP networks)
The AES70-1..3-R review of the AES70 standard is ongoing and maintained by SC-02-12-L. The group met before this meeting in Berlin, minutes and documents are available in the repository.
Berryman reported that the OCA Alliance has been working on their version 1.4 which has been uploaded to the repository. Berryman presented the headlines for the changes and additions to the protocol. Since the version uploaded a few more changes were added. A new version reflecting those changes will be uploaded shortly.
Going forward the SC-02-12-L will meet online on a weekly basis to get agreement on the changes. There is currently no timeline for when the revision will be ready for SC-02-12 voting.
The presentation of the changes resulted in some discussion:
- Adding UDP option to OCP.1 (AES70-3)
* Heinzmann asked if there was a definition of when to use UDP over TCP. Berryman stated that TCP should be used whenever available. UDP is intentioned for very simple devices (such as wall controllers) with strict memory limitations. Berryman agreed with Heinzmann that there is a risk that the less reliable UDP could be misused and that some direction would be needed as for when to use UDP.
* Is there any significant changes to a controller when controlling a UDP device instead of a TCP device. Berryman stated that there is not, except that UDP does not guarantee that the order of commands is preserved so in certain situations there might be differences.
* Cabot added that if strict ordering is required a controller could wait for the response acknowledge before issuing a new command.
- Adding a Task Class to the class tree (AES70-2)
* Heinzmann asked if real-time shouldn't be handled by RTP. Berryman clarified by noting that the intention of the task is to not have to rely on 'real time'. AES70 is a control protocol and issues requiring hard real-time or isochronous services would be outside the scope. Such things would fall under media transport which is deliberately not included in AES70.
- CM3 connection management (AES70-2)
* Grant asked if the AES67 connection management would make use of the 'reusable block method'. Berryman answered that the CM3 is a generic abstraction class and adaptations for AES67 would be published as common practice. Other adaptations for Dante and in the future AVB would be handled the same way. It was also mentioned that those adaptations would typically use the underlying native connection scheme and basically be a generic abstraction of what the specific media transports are providing or specifying.
* Berryman also stated that he will propose a project to create an 'Adaptation Bible' which would explain how to create media network adaptations and those would likely also use re-usable blocks. Berryman will provide a project proposal for this.
AES67-R - Review of AES67-2015 High-performance streaming audio-over-IP interoperability
The SC-02-12-M Task group met earlier in the day. Gross provided the update:
This is the second review of AES67, the first completed in 2015 contained correction of minor errors and updating of references.
The current review is in progress, the following items were mentioned as an overview:
- Missing RFC5939 references.
- Explanation of how to calculate MTU
- Recommendation for unicast transmitters with no receiver not to stream (avoid flooding)
- Fixing error in STP
- Major addition of 'PICS'
- New Informative clause on AMWA IS-04 discovery protocol. (Annex E)
Expecting a TG review to be conducted in about a month with a 2-3 week SC-02-12 review period following.
AES67 potential joint work with AES70
Cabot/Yonge stated that this work should start within SC-02-12-L as the scope of -M specifically excludes connection management and would require a change of scope. If it is deemed feasible a change of scope or a new TG could be requested. It is not possible to have the task reside in both L and M, as Grant noted it would be confusing from a reflector and repository point of view. Cabot also mentioned that it would confuse the issue of responsibility.
Berryman will move this forward by requesting a new project from SC-02 and it can then be decided where to place it.
Stevens mentioned that AMWA is conducting connection management sessions in Manchester next week and their work might be interesting to AES67. Gross noted that when AES67 last looked at CM in 2013 they found no usable CM scheme but things might have changed since.
Berryman reiterated that AES70 does not try to specify a connection management protocol, it simply provides a control abstraction for various connection management schemes for various media networks.
Plugfest schedule
The SC-02-12-M is looking for venues for a new plugfest. Various locations hosted by broadcasters were mentioned. The location must have a facility which supports the requirements and the location should be easily accessible via a major airport. Locations around LA, Houston, NY/NJ, Chicago and Washington were mentioned.
It was also mentioned that the FOX location might not have the kind of facilities which were available at the previous plug-fests in regard to the topology of the IT infrastructure.
Request: Gross would like to receive suggestions for plug-fest locations on the SC-02-12-M reflector.
AES-X238 Network Directory Architecture (SC-02-12-N)
Jeff Berryman reported:
The mission is as follows:
1- Call for requirements document to be created by X238
2- Distribution/Publishing
The document is almost done with one outstanding comment. When it is done it will be forwarded to the SC-02-12 for approval.
Cabot mentioned that an AES Report is not available for free. Berryman stated that it must be available for free or it would defeat the purpose. Yonge suggest it is treated as a Report while in the works and using a Report template. When published it can be published as a Call for Requirements or some other name the group will come up with (RFC should not be used as it can be confused with IETF RFC's)
After approval to publish Berryman envision a 3 months period to receive comments from the professional audio and video community including broadcast.
After receiving the comments, a requirement specification can be created. This would not be a standard but a requirement specification for a Network Directory Architecture.
Liaisons:
AES-X075 Liaison with IEC TC100 for IEC 61883
Junichi Yoshio reported:
No changes relating to IEC61883-6 and probably not going to be any, this is related to IEEE1394 and what is typically referred to as "AM824". While this is used by the IEEE 1722- 2011 (AVB) protocol it seems that even here the use of IEC61883-6 is being deprecated. Yoshio will continue to liaison with this group and monitor if other work relevant to SC-02-12 will emerge.
Liaison with MPEG
John Grant reported:
MPEG: has not been following this group much and has nothing new to report.
ETSI ISG NGP, Grant provided a better link than the one provided in the last report
The group is looking at network protocols for 5G, the next generation mobile standard. There are lots of things they want to support which have the same kind of latency requirements as pro audio. Trying to steer them and persuade them that there is more to networks than IT.
They are now reaching out to 3GPP which is a good thing as they would be the ones most capable. The #GPP will be meeting shortly and the 3GPP plenary will meet next month. If they take the bait this could be interesting.
Liaison with IEC62379-1
Peter Stevens reported:
Not much change from last time, needs to be completed by August 2018, some work started but slow in recent times.
Liaison with Ethernet AVB related working groups
Potential for an official liaison? Bruce Olson
No progress and problematic due to the difference in the two organizations policy regarding sharing, membership and disclosure.
However, it seems that a specific group within AvNU is looking at AES67 regarding AVB (interfacing etc.) and the chair (Lave) will reach out to see if an unofficial liaison can be made.
New Business:
Transport of audio metadata over IP networks
The AESSC has received a project initiation request from Dolby regarding Transport of audio metadata over IP networks. SC-02 will look at the request and determine in which working-group it belongs.
Next Meeting
The next meeting will be scheduled in conjunction with the AES 143rd Convention in New York, 2017-10.
