Re: [AVTCORE] Review of draft-ietf-avtcore-multi-party-rtt-mix

[Gunnar Hellström <[e-mail]>]

Hi Brian, thanks for good comments.

I want to start answering this comment:
"8. I don’t remember why you have to send the redundant text before 
switching sources. You might want to explain why in 3.11. It’s obvious 
you would like to do Particpant 1, initial, Participant 2, initial, 
Participant 1, redundant 1, Participant 2 redundant 2, Participant 1, 
redundant 2, Participant 2, redundant 2."

Good point. I have so far only specified use of the sequence number gap to detect packet loss and to evaluate if some redundant data in the latest received packet needs to be recovered. Then it is important that the source of the lost packets were the same as the source of the packet that we can pick the redundant data from.

Your idea to let sources shift more freely is good, and can be staisfied if we look at both sequence number gap and the contents of the timestamp offsets stored together with the redundant data in the packets.

The specification needs to be changed in sections 3.11 Source switching, 3.14 Rimer offset fields, 3.18.3 extraction , and 3.22 Packet sequence example.

In 3.11 the rule should be that when there is data available for transmission from more than one source, then a packet interval of 100 ms is recommended, and the packet to be composed and sent should have data from the source that has the oldest unsent data received in the mixer. All unsent data from that source shall be put in the packet as primary. Any earlier sent data from the same source shall be entered in the packet as before with timer offsets corresponding to when that data was sent as primary. This is done in two generations.

In 3.14 it shall be said that at reception, the primary data shall be retrieved. Then the timestamp of the latest received data from the same source evaluated against the calculated timestamps of the first redundant and second redundant data (by subtracting the timestamp offset from the timestamp). If any redundant data is younger, then that redundant data shall be retrieved and entered before the primary data mong received data from that source.

This algorithm may be simplified by doing it only if there had been any packet loss since latest reception from the same source as the last packet.

I need to check edge cases, e.g. when the loss is at the beginning or edge of a pause and other odd situations. And also what to do at the very rare occasions when many users create text simultaneously.

But in general I think this is daoable and creates better flow of text through the mixer.

Thanks

Gunnar

Den 2020-11-02 kl. 22:22, skrev Brian Rosen:
> I have reviewed -multi-party-mix-09 and have the following comments:
>
> 1. Section 1 Introduction provides the solution, in detail.  I think it would be better to have a high level description of the problem, and then introduce the solution in a subsequent section.  I would also like to see a little text on what “mixing” for rtt means.
>
> 2. In the Selected solution and considered alternatives section, the first alternative (One RTP stream per source in same RTP session), please make it clearer that the clients have to support this, not just the mixer, and that’s the issue.
>
> 3. I don’t really understand the text at the end of that section where it describes when multiple typers send text simultaneously.  ISTM that RTT behaves just like voice in that turn taking is often jumbled when more than one user responds to the previous user.  It takes time to recognize it, and for agreement on who has the “floor”.
>
> 4.  Need a better heading for “Specified Solutions”.  Actually, I wonder if you could delete this whole section, and add a definition for “multiparty aware” and “multiparty unaware” in 1.2.  Some of this text might move to 3 and 4.2, but that’s okay
>
> 5. If you did remove Section 2, you could rename Section 3 to Procedures for Multi-party aware mixing
>
> 6. The first two paragraphs of 3.1 are O/A text.  The last 3 aren’t - they are how parties act after O/A
>
> 7. In 3.3, it says “As soon as a participant is known to participate in a session and being available for text reception, a Unicode BOM character SHALL be sent to it according to the procedures in this section.”  I think it is unclear who sends this to whom.  I believe based on the text in 3.8, that the participant sends BOM to the mixer, because it says “and deletion of 'BOM' characters from each participant”.  Does the participant send it to the mixer?  Does the mixer send it to the new participant?  To existing participants?
>
> 8. I don’t remember why you have to send the redundant text before switching sources.  You might want to explain why in 3.11.  It’s obvious you would like to do Particpant 1, initial, Participant 2, initial, Participant 1, redundant 1, Participant 2 redundant 2, Participant 1, redundant 2, Participant 2, redundant 2.
>
> 9. Might want to add text before 3.18.1 that says why you want to send CSRC length 0.
>
> 10. Typo “evenso” in 3.19
>
> 11. Not sure I understand what “a negotiation between security and no security SHOULD be applied. ” (3.20) is supposed to mean.
>
> 12. Showing examples of SHA-1 may be realistic, but not desirable.
>
> 13. Possible discussion of malicious participants in Security Considerations.  Not much can be done, other than require secure signaling and media (so authentication can be relied upon).
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellström
GHAccess
[e-mail]