IEEE 1722.1 Agenda & Actions 20181212 IMPORTANT: New online meeting address: Zoom Meeting https://zoom.us/j/2268818568 One tap mobile +14086380968,,2268818568# US (San Jose) +16699006833,,2268818568# US (San Jose) Dial by your location +1 408 638 0968 US (San Jose) +1 669 900 6833 US (San Jose) +1 646 876 9923 US (New York) Meeting ID: 226 881 8568 Find your local number: https://zoom.us/u/cMjKFMQnr 1. Essential Patent Claim Notification Announcement 2. Antitrust and Competition Laws Compliance Announcement 3. (Don Pannell), Approval of F2F meeting minutes *** discussed mechanics of this since there is no current membership listing, there was no way to validate quorum to approve minutes. 4. (Don Pannell), status of upcoming 1722.1 working group election. *** Due to the long hiatus of this group, Dave Olsen and Don Pannell proposed that election notice be pushed out on the reflector and that those responding and voting (including a vote of "present") would become members of the group. 5. Call for suggestions for optimum meeting time for the 1722.1 working group. Is there a better time than 9AM Pacific Time Wednesday? *** Deferred until after the membership of the group has been re-established by the election process. 6. Review of the solutions and actions proposed during last weeks F2F meeting to reconcile "Milan" protocol requirements with the 1722.1 Standard. These items have been divided in to four categories: A. Clarification of the existing standard. B. Change existing standard. C. Fix/Correct an error in existing standard. D. Extend the existing standard in 1722.1-REV Reviewed the following items that were discussed at the F2F and took volunteers [ ] to create proposal/presentation for the editor, or to create presentations for future meetings so that consensus can be reached on items where there is still some contention. Categories are from the F2F presentation. A. Clarification of the existing standard. 01. AEM : SET_STREAM_FORMAT [Rimas Avizienis] 02. AEM : ADD_AUDIO_MAPPINGS [Rimas Avizienis] 03. AEM : REMOVE_AUDIO_MAPPINGS [Rimas Avizienis] 04. AEM : GET_AUDIO_MAP [Rimas Avizienis] 05. ACMP : STREAMING_WAIT [Rimas Avizienis] 06. ACMP/ AEM : Connection and acquired/locked state [Rimas Avizienis] 07. ACMP : Various clarifications of the fields of the ACMP messages [Rimas Avizienis] B. Change existing standard. 08. AEM : ACQUIRE_ENTITY command [Rimas Avizienis] 09. AEM : Sequence id for unsolicited notification messages [Rimas Avizienis] 10. ACMP : List of connected listeners maintained by the talker [Rimas Avizienis] 11. ACMP : ACMP and MAAP [Rimas Avizienis] 12. ADP : ADP Advertise state machine [not assigned] 13. AEM : Sample rate conversion [Rimas Avizienis] 14. ACMP : Fast Connect [Rimas Avizienis] 15. ACMP : Controller Connect sequence [Rimas Avizienis] 16. ACMP : Controller Disconnect sequence [Not resolved, will be presented at a future meeting as a proposal: Rimas to shepherd this.] C. Fix/Correct an error in existing standard. 17. ACMP : ACMP connection_count field [Not resolved, will be presented at a future meeting as a proposal: Marc Illouz] 18. ACMP : Rework the ACMP listener state machine [Not resolved, will be presented at a future meeting as a proposal: Marc Illouz and Rimas Avizienis to work on this.] 19. General : IN_PROGRESS [Not resolved, will be presented at a future meeting as a proposal: Marc Illouz and Rimas Avizienis to work on this.] D. Extend the existing standard in 1722.1-REV 20. AEM : Support for Redundancy [Richard Bugg for Cole Peterson] 21. AEM : GET_COUNTERS [Rimas Avizienis] 22. AEM : List of unsolicited notifications [Rimas Avizienis] 23. AEM : Extend GET_STREAM_INFO [Rimas Avizienis] The following are each of the Milan issues and proposed solutions discussed at the F2F, sorted into the four categories. A. Clarification of the existing standard. ::::::::::::::::::::::::::::::::::::::::Clarification::::::::::::::::::::: 01. AEM : SET_STREAM_FORMAT - The standard allows to set a format that would create dangling mappings. - The standard allows to change the format while the stream is connected (provided it is not streaming). *** need volunteer to prepare proposal/presentation for the editor: Rimas Mention in the standard that the entity may decide that the target format is not valid even if it is in the list of supported formats. ::::::::::::::::::::::::::::::::::::::::Clarification::::::::::::::::::::: 02. AEM : ADD_AUDIO_MAPPINGS - The standard allows to create dangling mappings. - The standard allows to add output mappings to a stream that is running *** need volunteer to prepare proposal/presentation for the editor: Rimas Mention in the standard that the entity may use vendor-specific rules to determine whether a list of mappings to add is valid or not. ::::::::::::::::::::::::::::::::::::::::Clarification::::::::::::::::::::: 03. AEM : REMOVE_AUDIO_MAPPINGS The standard allows to remove output mappings from a stream that is running *** need volunteer to prepare proposal/presentation for the editor: Rimas Mention in the standard that the entity may use vendor-specific rules to determine whether a list of mappings to remove is valid or not. ::::::::::::::::::::::::::::::::::::::::Clarification::::::::::::::::::::: 04. AEM : GET_AUDIO_MAP It’s not clear in the standard whether the number_of_mappings field of a GET_AUDIO_MAP response can be zero or not. *** need volunteer to prepare proposal/presentation for the editor: Rimas Mention in the standard that the entity may return GET_AUDIO_MAP responses with zero entry. ::::::::::::::::::::::::::::::::::::::::Clarification::::::::::::::::::::: 05. ACMP : STREAMING_WAIT It’s unclear in the standard how to use this bit on the talker. *** need volunteer to prepare proposal/presentation for the editor: Rimas The standard requires that the talker supports the CONNECT_TX_COMMAND. Add a note that a talker can reply INCOMPATIBLE_REQUEST in case it receives a CONNECT_TX_COMMAND with STREAMING_WAIT=1. ::::::::::::::::::::::::::::::::::::::::Clarification::::::::::::::::::::: 06. ACMP/ AEM : Connection and acquired/locked state The standard allows an entity to accept ACMP connection/disconnection requests no matter its current acquired/locked state. *** need volunteer to prepare proposal/presentation for the editor: Rimas Say that an entity shall refuse a connection/disconnection request from a controller if the STREAM_INPUT/OUTPUT descriptor is acquired/locked by another controller. ::::::::::::::::::::::::::::::::::::::::Clarification::::::::::::::::::::: 07. ACMP : Various clarifications of the fields of the ACMP messages - Flags field: which one is set by the controller, the listener, the talker? - stream_dest_mac: value when MAAP conflict after connection? - ... *** need volunteer to prepare proposal/presentation for the editor: Rimas initial start QUESTION: What additional fields of the ACMP messages are included in "..."? B. Change existing standard. !!!!!!!!!!!!!!!!!!!!!!!!! Change !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 08. AEM : ACQUIRE_ENTITY command A controller is able to acquire forever* all the devices of the network. We want to prohibit this usage in Pro Audio applications. In addition, the standard requires to use IN_PROGRESS responses when the entity is checking whether the acquiring controller is still alive. This is an issue (see the “IN_PROGRESS” topic). *** NO CHANGE IN STANDARD REQUIRED. *** Put into an "Informative Annex" for 1722.1 *** Volunteer needed to create entry for Informative Annex: Rimas *** We should decide which one of the three proposals below is best Three proposals were discussed during the F2F: - Make it optional. Pros: straightforward. Cons: breaks backwards compatibility. - Add a note in the standard (Informative Annex) saying that if an entity doesn’t want to be acquired, it should return NOT_AUTHENTICATED Pros: does not break backwards compatibility. Cons: may restrict the way we want to use authentication in the future. - Add a note in the standard (Informative Annex) saying that if an entity doesn’t want to be acquired, it should return ENTITY_MISBEHAVING. Pros: does not break backwards compatibility. Cons: the user may think that there is a bug. *Note that if the PERSISTENT Flag has not been set, another controller can acquire the entity and release it. (see Marc for Edge case where this is not true.) !!!!!!!!!!!!!!!!!!!!!!!!! Change !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 09. AEM : Sequence id for unsolicited notification messages 1722.1-Cor1 specifies how an entity must set the sequence id of unsolicited messages. Problems with the specified mechanism: 1) Implementation on the talker/listener is not convenient 2) The controller cannot detect a loss of unsol that happens between the registration and the first received unsol (because the controller doesn’t know the initial value of seqid) 3) The controller will detect a false loss if it sends a command (ex:SET_STREAM_FORMAT) and the reply from the entity is lost. The controller will not increment its local seqid and will think there was a lost next time it receives an unsol. Note: it was decided to use a global sequence id rather than a per-controller sequence id in order to save 16 bits per registered controller. *** need volunteer to prepare proposal/presentation for the editor: Rimas Use per-controller sequence id. Change the language and say that entities should use per-controller sequence ids. !!!!!!!!!!!!!!!!!!!!!!!!! Change !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 10. ACMP : List of connected listeners maintained by the talker The talker has to maintain a list of connected listeners but this list is not required to be accurate: - Some entries may be missing if the talker was connected to several listeners, has rebooted and is automatically advertising its Talker attribute. - Some entries may be erroneously present if the connected listeners have disappeared from the network without disconnecting. Furthermore, forcing the talker to maintain a list will artificially introduce a limit (due to memory constraints) to the number of simultaneously connected listeners. This is contrary to AVB principles, which is multicast without limitation to the amount of receivers. *** need volunteer to prepare proposal/presentation for the editor: Rimas State that maintaining the list of connected listeners is not required on the talker. Morton: Milan talkers could just not maintain the list and report 0 listeners. Informative Annex: Some implementations may not be able to keep a complete list. Note that the Milan spec can then elaborate that this should not be used. !!!!!!!!!!!!!!!!!!!!!!!!! Change !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 11. ACMP : ACMP and MAAP The standard mentions that the talker may run MAAP when it receives a CONNECT_TX_COMMAND. Because of this, the timeout is very big and this is not user-friendly (it takes almost 5 seconds to get an error response when the talker is not present). *** NO CHANGE IN STANDARD REQUIRED. *** Put into an "Informative Annex" for 1722.1 *** Volunteer needed to create entry for Informative Annex - - Rimas !!!!!!!!!!!!!!!!!!!!!!!!! Change !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 12. ADP : ADP Advertise state machine The standard requires to send ENTITY_AVAILABLE on all interfaces when receiving ENTITY_DISCOVER on an interface. *** need volunteer to check if this is really an issue or not. *** (Cole Peterson of Meyer may have offered to do this...) --- not assigned !!!!!!!!!!!!!!!!!!!!!!!!! Change !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 13. AEM : Sample rate conversion 1722.1-Cor1 says that ASYNC_SAMPLE_RATE_CONV and SYNC_SAMPLE_RATE_CONV cannot be set simultaneously. As these bits indicate support for a feature and not enabling of the feature, it should be possible to set them simultaneously. *** need volunteer to prepare proposal/presentation for the editor: Rimas Revert what is in the corrigendum. Clarify that it is a capability and add commands to set/get the current enabled state. Add a mechanism to check current state !!!!!!!!!!!!!!!!!!!!!!!!! Change !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 14. ACMP : Fast Connect For the sake of simplicity/usability, three different behaviors of the listener should be unified: - Successful connection made by Controller Connect, neither the listener nor the talker rebooted - Successful connection made by Controller Connect, then the listener has rebooted - Successful connection made by Controller, then the talker has rebooted *** need volunteer to prepare proposal/presentation for the editor *** Normative Annex entry to describe the following Fast Connect behavior: Rimas - If a listener supports Fast Connect, when it detects a problem (vendor-specific) with the input stream, it shall enter Fast Connect as if it had rebooted. - When a listener reboots in Fast Connect mode, it shall set CONNECTED to 1. - After a CONNECT_RX_COMMAND, a listener that supports Fast Connect will immediately reply with a CONNECT_RX_RESPONSE, and then enter Fast Connect as if it had rebooted. note: Marc and Cole may have offered to write this up and submit this solution to the 1722.1-REV !!!!!!!!!!!!!!!!!!!!!!!!! Change !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 15. ACMP : Controller Connect sequence See the “Fast Connect” topic. *** need volunteer to prepare proposal/presentation for the editor Rimas *** Normative Annex entry to describe the following Fast Connect behavior: Change the approach for the Controller Connect concept for listeners that support Fast Connect: present it as setting a parameter, not doing an action. The listener immediately sends the response, before contacting the talker, as it just updates a parameter (which is the “talker_entity_id,talker_unique_id” couple). The listener uses this parameter to update its Fast Connect behavior (try to connect to a talker, change the talker to which it is connected, etc.). Note: The CONNECT_RX_RESPONSE will not contain valid stream_id, dest_mac and vlan_id anymore. note: Marc and Cole may have offered to write this up and submit this solution to the 1722.1-REV !!!!!!!!!!!!!!!!!!!!!!!!! Change !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 16. ACMP : Controller Disconnect sequence There is no defined state for ongoing disconnection on the listener. If the listener is repeatedly connected/disconnected and the talker never replies to DISCONNECT_TX_COMMAND, the listener will have to maintain a lot of disconnection contexts and may lack of resources; this would result in undefined behavior. Change the approach for the Controller Disconnect concept for listeners that support Fast Connect: present it as clearing a parameter, not doing an action. Don’t require the listener to send DISCONNECT_TX_COMMAND when it receives a DISCONNECT_RX_COMMAND. Note: this is consistent with the proposal for the “List of connected listeners maintained by the talker” topic. Milan discussion: The standard could still require sending the DISCONNECT_TX_COMMAND while specific applications could decide not to do it as it does not break backwards compatibility. Note: in the standard, it should be required to refuse a CONNECT_RX_COMMAND when the listener is waiting for the DISCONNECT_TX_RESPONSE from the talker. note: Marc/Cole to write this up and submit this solution to the 1722.1-REV Milan will need a way to be able to ignore this but still comply. -- not resolved, Needs to be presented at a future meeting as a proposal: Rimas to shepherd this. C. Fix/Correct an error in existing standard. ========================================fix============================= 17. ACMP : ACMP connection_count field Section 8.2.1.15 says that it’s the number of connections the talker thinks it has. But: - In GET_RX_STATE_RESPONSE, it is rather the state of the listener - In GET_TX_CONNECTION_COMMAND/RESPONSE, it is the index of the target connection In GET_RX_STATE_RESPONSE: - 0 if the sink is not connected - 1 if the sink is connected In GET_TX_CONNECTION_COMMAND/RESPONSE: index of the target connection *** *** DO WE HAVE CONSENSUS ON THE FOLLOWING POINTS?: *** In GET_RX_STATE_RESPONSE: - 0 if the sink is not connected - 1 if the sink is connected In GET_TX_CONNECTION_COMMAND/RESPONSE: index of the target connection -- Not resolved, will be presented at a future meeting as a proposal: Marc Illouz ========================================fix============================= 18. ACMP : Rework the ACMP listener state machine Several CONNECT_RX_COMMAND are allowed to be processed in parallel; several talkers may receive a CONNECT_TX_COMMAND but at the end only one will be connected (for which the CONNECT_TX_RESPONSE has been receive first by the listener). In addition, as the listener has limited resources, this may result in undefined behavior of the listener. *** *** DO WE HAVE CONSENSUS ON THE FOLLOWING POINTS?: *** Who will review the state machines? *** Don’t allow more than 1 inflight connection command for listeners that do not implement Fast Connect. Note: for listeners that implement Fast Connect, the behavior should be as described in the “Controller Connect sequence” topic. -- Not resolved, will be presented at a future meeting as a proposal: Marc Illouz and Rimas Avizienis to work on this ========================================fix============================= 19. General : IN_PROGRESS Fix - An entity should not be required to support IN_PROGRESS because support of this may result in the entity being unable to process all the other commands received while it is in the IN_PROGRESS state (because the entity has limited resources). This would result in undefined behavior. - A controller should not be required to support IN_PROGRESS because it may be blocked for an indeterminate amount of time when it is receiving IN_PROGRESS messages. There is no timeout defined in the standard, and there is no way to abort a command which is in progress. - *** *** DO WE HAVE CONSENSUS ON THE FOLLOWING POINTS?: *** There seem to be some open questions on this issue *** I believe there is already a way to deal with ACQUIRE_ENTITY using AUTHENTICATION_REQUIRED. *** Do not require support for IN_PROGRESS (in particular, do not require implementation of ACQUIRE_ENTITY as it is using IN_PROGRESS) Mention that a controller is allowed to treat IN_PROGRESS as an error code For the talker/listener: IN_PROGRESS is required for ACQUIRE_ENTITY only (an entity is allowed to reply ENTITY_MISBEHAVING if it doesn’t want to implement ACQUIRE_ENTITY). For other commands like SET_STREAM_FORMAT, it may be used or not, it’s up to the implementation. For the controller: we should work in the standard on a way to cancel a command that sends IN_PROGRESS or detect that the entity has crashed in an infinite loop sending IN_PROGRESS messages forever. -- Discuss again in a future meeting so that this is fully vetted. Clarifications needed, what should happen if entity has failed/crashed. Rimas & Marc (Christoph, perhaps maximum time-out) D. Extend the existing standard in 1722.1-REV ----------------------------------Extension-------------------------- 20. AEM : Support for Redundancy A way is needed to associate streams that constitute a redundant pair, so that a controller knows which stream is redundant of which other stream. *** need volunteer to prepare proposal/presentation for the editor: Extend the STREAM_INPUT/OUTPUT descriptor. See http://grouper.ieee.org/groups/1722/1/contributions/2017/Peterson_redundant_streams_association.pdf Also: mention that it is allowed to set the same dynamic mapping from the two streams of a redundant pair in STREAM_PORT_INPUT. - need a presentation for discussion in a future meeting: (move Cole presentation to public) Richard ----------------------------------Extension-------------------------- 21. AEM : GET_COUNTERS We need diagnostic counters for output streams (STREAM_OUTPUT descriptors). *** need volunteer to prepare proposal/presentation for the editor: Rimas Add counters for STREAM_OUTPUT: - STREAM_START - STREAM_STOP - MEDIA_RESET - TIMESTAMP_UNCERTAIN - FRAMES_TX ----------------------------------Extension-------------------------- 22. AEM : List of unsolicited notifications Some important state changes are missing from the standard list of unsolicited notifications. *** need volunteer to prepare proposal/presentation for the editor: Rimas Add unsolicited notifications: - LOCK_ENTITY - GET_COUNTERS - DEREGISTER_UNSOLICITED_NOTIFICATION ----------------------------------Extension-------------------------- 23. AEM : Extend GET_STREAM_INFO Some stream information deserve to be reported and notified automatically when they change. They should be added to the GET_STREAM_INFO message. *** need volunteer to prepare proposal/presentation for the editor: Rimas Add fields at the end of the GET_STREAM_INFO response message: - REGISTERING: the listener is registering a Talker Advertise or a Talker Failed. - PROBING_STATUS: state of Fast Connect process - ACMP_STATUS: status code of the last received CONNECT_TX_RESPONSE. Do NOT add fields at the end of the GET_STREAM_INFO message. Instead use an additional bit of the "flags" to report whether the additional information is present or not, and put this additional information in reserved flags and reserved fields.