Re: [AVTCORE] WG Last Call: "RTP-mixer formatting of multi-party Real-time text"

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Sun, 06 December 2020 09:56 UTC

Return-Path: <gunnar.hellstrom@ghaccess.se>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52A13A0A1D for <avt@ietfa.amsl.com>; Sun, 6 Dec 2020 01:56:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suknV3y5WyZy for <avt@ietfa.amsl.com>; Sun, 6 Dec 2020 01:56:31 -0800 (PST)
Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B28E3A09E1 for <avt@ietf.org>; Sun, 6 Dec 2020 01:56:29 -0800 (PST)
Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 70F542003E; Sun, 6 Dec 2020 10:56:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1607248587; bh=mykGodOQWuX8BWZnlGHTw2T+/pOgaahoWxKyOAIuPyU=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From; b=cjw7NL0Je0NXKbJ/lG2CEMGYqXXUkkznQEk+3+c+mqYnJylqCWEOUFSF0855PacYF lPF/gbS0VwbsSPUwNl14sA++33TsngiDeQdEa57sLbsuPXtBYKnx5gTXibp9xHct3J 7xzEnoruRAc9XHTI4rVba+Ds36A67TWrbK2Oyqko=
From: Gunnar Hellström <gunnar.hellstrom@ghaccess.se>
To: Brian Rosen <br@brianrosen.net>
Cc: IETF AVTCore WG <avt@ietf.org>
References: <CAOW+2duJwBizifn94qcRfpZ6cqRjRVyueyoofox0AWjkcJm02g@mail.gmail.com> <68866CAE-C81B-4C23-9DB5-CA8B57C1E3DC@brianrosen.net>
Message-ID: <8d4645e7-3c30-0bff-134c-a0d27727d35f@ghaccess.se>
Date: Sun, 06 Dec 2020 10:56:27 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <68866CAE-C81B-4C23-9DB5-CA8B57C1E3DC@brianrosen.net>
Content-Type: multipart/alternative; boundary="------------A462D8ACD50822B5310DD934"
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/HZQcBC-3pcy95--hCehzcnppj04>
Subject: Re: [AVTCORE] WG Last Call: "RTP-mixer formatting of multi-party Real-time text"
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Dec 2020 09:56:38 -0000

Brian,

Thanks for review and proposals.

I am preparing modifications as commented below.

Den 2020-12-04 kl. 18:27, skrev Brian Rosen:
> I have reviewed 
> https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix-11 
> <https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix-11>
>
> Although there are quite a few comments below, only the last one is 
> possibly a normative change.  I would be fine with having these 
> comments addressed in whatever the next revision to the document is, 
> rather than hold up IETF last call. I support advancing this document 
> to Proposed Standard.
>
> 1. I don’t think it’s necessary to say "Regional regulatory 
> requirements specify provision of real-time text
>    in multi-party calls” in the abstract.  It’s true, but the IETF 
> usually doesn’t do things because governments make them a requirement. 
>  Instead, I might say something like “Use of RTT is increasing, and 
> specifically, use in emergency calls is increasing.  Emergency call 
> use requires multiparty mixing”.  I’d just delete the reference to 
> regulatory requirements in the Introduction section.
>
[GH] I wait with a response on this one.
> 2. This is a run-on sentence:
>     ...The presentation can
>     then be arranged so that text from different sources can be presented
>     in real-time and easily read while it is possible for a reading user
>     to also perceive approximately when the text was created in real time
>     by the different parties.
> Perhaps “The presentation can then be arranged so that text from 
> different sources can be presented
>    in real-time and easily read.  It is also possible for the 
> presentation to indicate approximately when the text was created in 
> real time
>    by the different parties.”

[GH]Accepted.  I suggest the second sentence to be: " At the same time 
it is possible for a reading user to perceive approximately when the 
text was created in real time by the different parties."


>
> 3. In 1.1. this text appears: "and in most applications also more than 
> three parties in a call is rare”.  As anyone experiencing this past 
> year can attest, that is not true :). The first part of the sentence 
> is true, and I think this can just be deleted.
[GH] Accepted.
>
> 4. The heading "The presentation planned by the mixer for multi-party 
> unaware endpoints” is not great English.  Could be “Mixer provides 
> presentation of multiple parties”
[GH] I suggest "Mixer prepares presentation of text from multiple parties"
>
> 5. In section 1.2 could we not say “as defined in” rather than “are 
> explained in” for RFC3550?
[GH] Accepted
>
> 6. <not a request to change> I had to look up the definition of 
> “utterance” to see that in linguistics, it means “an uninterrupted 
> chain of spoken or written language”, so it’s correctly used here.
;-)
>
> 7. In this subsection (Intended use), would it be good to mention the 
> issue of backspace when dealing with multiple parties?  I always found 
> that the best example of why it’s hard to to this centrally.
[GH] Would it help by inserting this paragraph after the second 
paragraph in 1.3?
"        Users expect that the text they send is presented in real-time 
in a readable way to the other participants even if they send 
simultaneously with other users and even when they make brief edit 
operations of their text by backspacing and correcting their text. "
>
> 8. In 2.2 it says “does not itself implement any solution for 
> multi-party handling of real-time text.”  It’s actually that it 
> doesn’t meet this document's “multiparty-aware” specification: if you 
> don’t negotiate the use of the mechanism specified here, then you use 
> this multiparty unaware mechanism.  It could implement some other 
> mechanism but if the mixer didn’t support it, it wouldn’t work.

[GH] I suggest to change the beginning of 2.2 to:

" A method is also specified in this document for cases when the 
endpoint participating in a multi-party call does not itself implement 
the solution for multi-party handling of real-time text specified in 
section 3. The method requires the mixer to insert text dividers and 
readable
     labels and only send text from one source at a time until a 
suitable point appears for source change."

>
> 9. 3.6 missing “the” in "It is RECOMMENDED to send next packet to..” 
>  So “.. send the next packet”
[GH] Accepted
>
> 10. In 3.7 it says “New and redundant text from one source SHALL be 
> transmitted in the same packet”.  Is that explained in 4103?  It’s old 
> redundant text and new text.  Not new text and a redundant copy of the 
> new text.  Maybe could use a bit of explaining.
>
[GH] I suggest to start the section with: "New text and redundant copies 
of earlier text from one source SHALL be transmitted in the same packet"

> 11. Minor English issues in 3.8.  Say “Text received by a mixer from a 
> participant..”
>
[GH] Accepted
> 12. Minor English in 3.12.  Say “the participant whose text is included”
[GH] Accepted
>
> 13.  Think about expanding WHY you must consider integrity for RTCP 
> (3.18).  Also ".. considerations SHALL be considered" isn’t great 
> construction.

[GH] This sentence was added after a discussion related to emergency 
services. A thought was that a bridge within an emergency service 
network would be required to send quite anonymous NAME information about 
the calltakers to the user in emergency, while the bridge would send 
more detailed NAME fields to other emergency service agents. This sounds 
too application specific to explain here. But I tried to add some 
wording resulting in this text: Maybe it is too much?

"Integrity SHALL be considered when composing these fields. They contain 
name and address information that may be sensitive to transmit in its 
entirety e.g. to unauthenticated participants. Similar considerations 
SHOULD be taken as for other media."
>
> 14. 3.19.1, if the receiver is a mixer, then CC=0 doesn’t mean point 
> to point in the sense you intend here.  It’s text from a participant, 
> as opposed to text from a mixer, in a multiparty call.
>
[GH] Right. I see that the use of CC and the source indication needs a 
bit more clarification. In a couple of places it is said that the mixer 
shall create data and send it with its own SSRC as source. That is when 
sending the initial BOM to a participant.

Therefore, I propose to change 3.19.1 to

"3.19.1.  Acting on the source of the packet contents

    If the "CC" field value of a received packet is 1, it indicates that
    the text is conveyed from a source indicated in the single member in 
the CSRC-list, and the receiver MUST act on the source according to its 
role. If the CC value is 0, the source is indicated in the SSRC field."

and 3.3 change from:

"3.3.  Use of fields in the RTP packets

    The CC field SHALL show the number of members in the CSRC list, which
    SHALL be one (1) in transmissions from a mixer involved in a multi-
    party session, and otherwise 0.

    When transmitted from a mixer during a multi-party session, a CSRC
    list SHALL be included in the packet.  The single member in the CSRC-
    list SHALL contain the SSRC of the source of the T140blocks in the
    packet."

To

"3.3.  Use of fields in the RTP packets

    The CC field SHALL show the number of members in the CSRC list, which
    SHALL be one (1) in transmissions from a mixer when conveying text from
other sources in a multi-party session, and otherwise 0.

    When text is conveyed by a mixer during a multi-party session, a CSRC
    list SHALL be included in the packet.  The single member in the CSRC-
    list SHALL contain the SSRC of the source of the T140blocks in the
    packet."


> 15. Are 13.19.2 and 13.19.3 just restating what 4103 says?  If they 
> are, then consider deleting
>
[GH] Yes, they are. Deleted.
> 16. Minor English, say “SHALL be regarded as lost”
[GH] Accepted
>
> 17. In 3.19.4, you have a normative “a t140 block SHALL be created”, 
> but then later you say “Implementations MAY apply more refined 
> methods”.  Doesn’t that make that SHALL a SHOULD?  Also, minor 
> English, say something like “SHOULD prefer marking possible loss 
> rather than not marking when it is uncertain if there is loss”
[GH] Accepted as proposed.
>
> 18. In 3.21, you have two cross references to the same RFC in the same 
> sentence.  One can be deleted.
[GH] If you mean that "RFC 8643 OSRTP [RFC8643]" should be "OSRTP 
[RFC8643]" it is accepted.
>
> 19. 3.23, minor English: say “Packet 103 is assumed to be lost due to 
> network problems”.
>
[GH] Accepted
> 20. In 3.24 it says 'A value for "CPS" of 90 is the default for the 
> "text/t140" stream in the  "text/red" format when multi-party 
> real-time text is negotiated.’   Is that a restatement of what 4103 
> says, or a normative statement this document makes?  Please make it 
> more clear.
[GH] It is new normative here. I propose to change "is the default" to 
"SHALL be the default"
>
> 21. In 4.1 normative MUST/MAY/SHOULD is used to describe user 
> interface.  Is that appropriate? Same for 4.2

[GH] I think the normative wording is appropriate for 4. and 4.1. 
Normative wording is used wherer it is essential to treat incoming data 
in a specific way to not cause garbling or other confusion and thereby 
be able to fulfill the intentions of T.140 cited in the second paragraph 
of 4. Total freedom is left for the user interface in other aspects.

For 4.2 you may be right that many of the normative words could be 
changed to non-normative (except some related to the stream contents as 
you point out in #22). 4.2 is a best-effort procedure, and other 
procedures may be specified.  As a start, I suggest to change the second 
SHALL of 4.2.1 (about the time) to SHOULD.

With that change, all normatives about the presentation procedure are 
SHOULDs. Together they form a recommended procedure. Would it be better 
to change all these to lower case "should" and rely on the introduction 
in 4.2 to recommend to follow the procedure when the capability 
negotiation fails?

>
> 22.  On the other hand, in 4.2.1, there is a lower case “.. BOM 
> characters … shall be deleted”.  That might want to be SHALL.
[GH]Accepted.

>
> 23. In the beginning of 4.2.2, is the “SHOULD be applied for each 
> recipient of multi-part text” actually “...non multi-party aware 
> recipient”?
[GH] Yes, I suggest to use "each multi-party unaware recipient" instead 
because that is used in other places.
>
> 24. (The only possibly normative change) 4.2.5 says the mixer should 
> send primary data from one source per packet.  Why is that?  The mixer 
> is creating a single stream that contains all the display for the 
> mixed participants.  ISTM there is nothing gained by this restriction, 
> and it means lots of extra packets.

[GH] Handled in another response.

With that, I view #1 as not handled yet, and #21 needing another 
consideration for the SHOULDs in 4.2.x

Thanks

Gunnar

>
>
> Brian
>
>
>> On Nov 25, 2020, at 5:16 PM, Bernard Aboba <bernard.aboba@gmail.com 
>> <mailto:bernard.aboba@gmail.com>> wrote:
>>
>> This is an announcement of WG last call on "RTP-mixer formatting of 
>> multi-party Real-time text"
>>
>> The document is available for inspection here:
>> https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix 
>> <https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix>
>>
>> WG Last Call will end on December 9, 2020.
>>
>> In response, please state one of the following:
>>
>> * I support advancing the document to Proposed Standard
>> * I object to advancement to Proposed Standard, due to Issues 
>> described below <Issue description or link>.
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org <mailto:avt@ietf.org>
>> https://www.ietf.org/mailman/listinfo/avt
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se