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

From: Gunnar Hellström <[email-masked]>
Date: Fri, 9 Oct 2020 21:36:51 +0200

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 [email-masked]:
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/avt
>
-- 
Gunnar Hellström
GHAccess
[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 10 Oct 2020 14:50:20 -0400

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/

* 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?

* Section 2.1.18.3:

There are two instances of "deduct" here that I think should be "deduce".

* 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.

In the second paragraph:  s/the the/the/

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.

* 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.

* 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.

* Section 8.1:

Please just omit "Attribute syntax:  a=rtt-mix-rtp-mixer". It is only 
for attributes that have values.

That's all. Generally looking good.

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 12 Oct 2020 16:35:01 +0200

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:
> 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:
>
Accepted and Done
> 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.

> There are two instances of "deduct" here that I think should be "deduce".
Accepted and done
> unclear. I presume it means section 2.1 rather than section 2.1.20 or 
Yes, done.
> In the second paragraph:  s/the the/the/
Accepted and done
> "rtt-mix-rtp-mixer" *has* been negotiated.
Accepted -  will do together with next.
> discussion of the alternative and a delegation to the new section for 
Accepted - will do
> Do you think this is sufficient for implementors? You may want to say 

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."

> for attributes that have values.
Accepted and done.
>> 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".
>>
>>>>     A specifications of how a mixer can format text for the case 
>>>> when the

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Oct 2020 11:04:45 -0400

> Will continue with the proposed restructuring of section 2.1.

Sounds good.

> See a few comments below.

I have one followup comment below.

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

When I looked at "rtt-mix-rtp-mixer" my first thought was as you 
describe - that there would be several attributes pertaining to rtt 
mixers. But then I found no others in the draft, and none starting with 
"rtt-mix" already in the iana registry. So simplifying seemed in order.

But, if you foresee some possibility of others being defined in the 
future then it might indeed be worth planning for that now. As you see 
fit, or perhaps it should be further discussed.

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 12 Oct 2020 21:48:53 +0200

See answer below,

Den 2020-10-12 kl. 17:04, skrev Paul Kyzivat:
>> 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.
>>
>> 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.
>>
> mixers. But then I found no others in the draft, and none starting 
> with "rtt-mix" already in the iana registry. So simplifying seemed in 
> order.
>

I hope that the current draft is what we need for SIP based services. 
And I hope that the SIP environment will be the only one where 
implementations got spread without multi-party support. The presentation 
level standard T.140 requires multi-party support, but the 
implementations did not fulfill that. That is why we now need the 
attribute.

The next environment where I expect RTT to spread is in WebRTC, where 
the to-be RFC 8865 specifies how to transport RTT in data channels. In 
that spec the normal way to handle multi-party is by multiple data 
channels. The normal design would be to support additions of data 
channels in a session. A bridge would detect if addition of a channel 
for a new participant is unsuccessful and can take that as an indication 
that multi-party is not supported ( or the maximum number of supported 
participants is reached) and take appropriate action.

So, at the moment, I do not see a need for other multi-party rtt attributes.

Thanks,

Gunnar