Re: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix-08.txt - please review

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

Paul, thanks for the review,

I have accepted all your proposals and done the easy ones in my draft.

Will continue with the proposed restructuring of section 2.1.

See a few comments below.

Thanks,

Gunnar

Den 2020-10-10 kl. 20:50, skrev Paul Kyzivat:
> Gunnar,
>
> I haven't commented on this for some time because it seemed to be 
> progressing well and those contributing know more about RTP and RTT 
> than I do. Now that it seems to be approaching technical completeness 
> (and because I was asked) I have reviewed it again. Here are my thoughts:
>
> * Section 1:
>
> s/by shorting the/by shortening the/
Accepted and Done
>
>
> * Section 2.1:
>
> Why was "rtt-mix-rtp-mixer" chosen as the name of the attribute? It 
> seems cumbersome and redundant. Wouldn't "rtt-mixer" be sufficient?
Yes, a better name may be needed.
draft-hellstrom-avtcore-multi-party-rtt-solutions has in sections 6.3 
and 6.4 a discussion on the sdp attribute. I agree that the name is long 
and maybe confusing. The thought is that the first part, "rtt-mix", 
indicates the purpose: to indicate support for a type of mixer for 
real-time text. The second part, "rtp-mixer", indicates what type of 
mixer that is supported. It is the rtp-mixer style as described in RFC 
3550.

There is no plan right now, but it would be possible that later work 
specifies another mixer type as an alternative. It could be a 
multi-stream mixer using the rtp-translator style from RFC 3550. That 
work could then register another attribute, e.g. called 
"rtt-mix-rtp-translator". That is not sufficiently likely to motivate 
the effort to now create an attribute with values, but the reasoning 
motivated a name that indicates both the purpose and the solution.

That said, looking at your name proposal "rtt-mixer", I find that it can 
meet the criteria. "rtt-" indicates that it is about real-time text, and 
"mixer" can be taken to mean the "rtp-mixer" style. It was also used as 
the name in early versions of this draft.

So, the simple conclusion is: Yes, accepted and done.

>
> * Section 2.1.18.3:
>
> There are two instances of "deduct" here that I think should be "deduce".
Accepted and done
>
> * Section 2.1.20:
>
> In the first and second paragraphs the reference to "this section" is 
> unclear. I presume it means section 2.1 rather than section 2.1.20 or 
> section 2.
Yes, done.
>
> In the second paragraph:  s/the the/the/
Accepted and done
>
> The third paragraph seems inappropriate for this section of the 
> document, since this section is intended to apply only in cases where 
> "rtt-mix-rtp-mixer" *has* been negotiated.
>
Accepted -  will do together with next.
> * Section 2.2:
>
> The document specifies two alternative mechanisms, one in 2.1 and the 
> other in 2.2. But the formatting is very weird because section 2.1 is 
> long and detailed while section 2.2 is very short and delegates 
> everything to section 3.2.
>
> I suggest reorganizing the document to make this cleaner. E.g., move 
> most of the content of content of section 2.1 (all the 2.1.x sections) 
> to a new top level section. Then replace that with a small high level 
> discussion of the alternative and a delegation to the new section for 
> the details.
Accepted - will do
>
> * Section 3.1:
>
> You talk about "When text is received from multiple original sources 
> simultaneously". The meaning of "simultaneously" is pretty fuzzy here. 
> Do you think this is sufficient for implementors? You may want to say 
> more.

It is intended to say that each source has its own insertion point in 
the presentation areas and that text can be added to any of these 
insertion points in real time. That is approximately what is said in the 
paragraph above the sentence.

So maybe the sentence is not needed.

I suggest to change it to:

"When text is received from multiple original sources, the presentation 
SHOULD provide a view where text is added in multiple presentation fields."

>
> * Section 8.1:
>
> Please just omit "Attribute syntax:  a=rtt-mix-rtp-mixer". It is only 
> for attributes that have values.
Accepted and done.
>
> That's all. Generally looking good.
>
>     Thanks,
>     Paul
>
> On 10/9/20 3:36 PM, Gunnar Hellström wrote:
>> I would like to get review comments on 
>> draft-ietf-avtcore-multi-party-rtt-mix-08.txt.
>>
>> There are three small changes pending:
>>
>> 1. The reference to the WebRTC transport of T.140 real-time text is 
>> about to be changed from 
>> draft-ietf-mmusic-t140-usage-data-channel-14.txt to RFC 8865, but 
>> even if RFC 8865 is ready, it is awaiting common publication of a 
>> cluster of WebRTC related drafts.
>>
>> 2. A bit more detail in section 2.1.23 about the recovery situations 
>> in case of packet loss.
>>
>> 3. Correction of a minor error  in 2.1.23, where "A1" in the text 
>> under packet 6 should be "A3".
>>
>> Any further comments would be appreciated so that the draft can be 
>> progressed.
>>
>> /Gunnar
>>
>>
>> Den 2020-08-12 kl. 20:52, skrev Gunnar Hellström:
>>> A new version of the "RTP-mixer formatting of multi-party Real-time 
>>> text" is available.
>>>
>>> This version moves forward with only two methods for multi-party 
>>> mixing of RTP transported real-time text.
>>>
>>> The major one is RFC 4103 with transmission interval of 100 ms when 
>>> there is text from more than one source to transmit, and source 
>>> indicated in the CSRC list.
>>>
>>> The second one is the fallback for the situation that the endpoint 
>>> does not have multi-party capability.
>>>
>>> Regards
>>>
>>> Gunnar
>>>
>>> Den 2020-08-12 kl. 20:44, skrev [e-mail]:
>>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>>> directories.
>>>> This draft is a work item of the Audio/Video Transport Core 
>>>> Maintenance WG of the IETF.
>>>>
>>>>          Title           : RTP-mixer formatting of multi-party 
>>>> Real-time text
>>>>          Author          : Gunnar Hellstrom
>>>>     Filename        : draft-ietf-avtcore-multi-party-rtt-mix-08.txt
>>>>     Pages           : 36
>>>>     Date            : 2020-08-12
>>>>
>>>> Abstract:
>>>>     Real-time text mixers for multi-party sessions need to identify 
>>>> the
>>>>     source of each transmitted group of text so that the text can be
>>>>     presented by endpoints in suitable grouping with other text 
>>>> from the
>>>>     same source.
>>>>
>>>>     Regional regulatory requirements specify provision of real-time 
>>>> text
>>>>     in multi-party calls.  RFC 4103 mixer implementations can use
>>>>     traditional RTP functions for source identification, but the mixer
>>>>     source switching performance is limited when using the default
>>>>     transmission characteristics with redundancy.
>>>>
>>>>     Enhancements for RFC 4103 real-time text mixing is provided in 
>>>> this
>>>>     document, suitable for a centralized conference model that enables
>>>>     source identification and source switching.  The intended use 
>>>> is for
>>>>     real-time text mixers and multi-party-aware participant endpoints.
>>>>     The specified mechanism build on the standard use of the CSRC 
>>>> list in
>>>>     the RTP packet for source identification.  The method makes use of
>>>>     the same "text/red" format as for two-party sessions.
>>>>
>>>>     A capability exchange is specified so that it can be verified 
>>>> that a
>>>>     participant can handle the multi-party coded real-time text 
>>>> stream.
>>>>     The capability is indicated by use of a media attribute 
>>>> "rtt-mix-rtp-
>>>>     mixer".
>>>>
>>>>     The document updates RFC 4103[RFC4103]
>>>>
>>>>     A specifications of how a mixer can format text for the case 
>>>> when the
>>>>     endpoint is not multi-party aware is also provided.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ 
>>>>
>>>>
>>>> There are also htmlized versions available at:
>>>> https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix-08
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-multi-party-rtt-mix-08 
>>>>
>>>>
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-08 
>>>>
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of 
>>>> submission
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>>
>>>> _______________________________________________
>>>> Audio/Video Transport Core Maintenance
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/avt
>>>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt

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