Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t140-usage-data-channel - modification proposals

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Sun, 25 August 2019 05:17 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A4112010F for <mmusic@ietfa.amsl.com>; Sat, 24 Aug 2019 22:17:35 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 nDyHUyuMhzXZ for <mmusic@ietfa.amsl.com>; Sat, 24 Aug 2019 22:17:32 -0700 (PDT)
Received: from vsp-unauthed02.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE471120100 for <mmusic@ietf.org>; Sat, 24 Aug 2019 22:17:31 -0700 (PDT)
X-Halon-ID: 997da3b5-c6f7-11e9-bdc3-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [88.129.173.120]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id 997da3b5-c6f7-11e9-bdc3-005056917a89; Sun, 25 Aug 2019 07:17:15 +0200 (CEST)
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@ericsson.com> <CAOW+2duTuUc8FXT-BEhJioUnPsOkzYJddK=xAp1oWiBQCKM2vg@mail.gmail.com> <HE1PR07MB3161874ED292FA17015EF95E93AE0@HE1PR07MB3161.eurprd07.prod.outlook.com> <665185b6-c1e7-62c3-4e3b-e9374d23bfd5@omnitor.se> <DF010721-81CD-40DE-A848-DE4D36836FDA@ericsson.com> <ED158CF5-E059-482B-8D7E-934BA2C753A1@ericsson.com> <2201665d-5054-1872-d208-a0fe2d26095c@omnitor.se> <VI1PR07MB3167055C995D17D4BA9E36DE93A50@VI1PR07MB3167.eurprd07.prod.outlook.com> <8d14b055-8405-4a4f-174d-d7580bea348c@omnitor.se> <0DA1248C-41FC-4155-A578-29A19883857C@ericsson.com> <a91850b9-6e86-058f-dddd-3f856bcd6710@omnitor.se> <DBC532B8-38DC-4140-B7C4-0B6853F0EF77@ericsson.com> <6fcf46a6-544d-027c-97c7-5c0e08caa555@omnitor.se> <HE1PR07MB3161A9A0C696B9636BBD380C93A70@HE1PR07MB3161.eurprd07.prod.outlook.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <36558f91-106c-aa4c-c885-6a866d3ed9f2@omnitor.se>
Date: Sun, 25 Aug 2019 07:17:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <HE1PR07MB3161A9A0C696B9636BBD380C93A70@HE1PR07MB3161.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/_r9cxYrAixIWdPt4U9Xqou8OZcs>
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t140-usage-data-channel - modification proposals
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Aug 2019 05:17:36 -0000

Christer,

I am satisfied with all your responses and actions except for number 18, 
the multi-party case. I will handle that in a separate answer.

For number 16, I had no reason for not inserting "real-time text" in the 
sentence you asked about.

Thanks, no inline comments here.

Gunnar

Den 2019-08-24 kl. 12:04, skrev Christer Holmberg:
> Hi Gunnar,
>
> Thank You for the detailed review and suggestions! Please see inline.
>
>> Here is a first set of modification proposals for the topics I have mentioned, and a few more editorial, but
>> lacking the end-to-end encryption requirement for the interworking case that I do not know how to handle.
> Maybe that should be looked at as a separate delivery, probably in a separate WG (AVT?).
>
>> I hope you can handle the simple change proposal format.
> That's fine - based on the outcome of your comments I will update the pull request :)
>
> -----------------------------------------------------------------------
>
>> 1. Change the title from
>>
>> "T.140 Text Conversation over WebRTC Data Channels"
>>
>> to
>>
>> "T.140 Real-time Text over WebRTC Data Channels"
>>
>> Reason: Real-time text is the current term for Text Conversation
> See my reply to comment #3.
>
> ------------------------------------------------------------------------------------------
>
>> 2. Modify the second line of the abstract from
>>
>> "transport mechanism for the ITU-T Protocol for multimedia application"
>>
>> to
>>
>> "transport mechanism for Real-time text media using the ITU-T Protocol for multimedia application"
>>
>> Reason: Real-time text is an important keyword for this media.
> See my reply to comment #3.
>
> -------------------------------------------------------------------------------------
>
> 3. In 1. Introduction, line 3, change from
>
>>     "conversation, also known as realtime text or text telephony. The"
>>
>> to
>>
>>     "conversation, also known as real-time text.  The"
>>
>> Reason: Text telephony may use T.140, but is not required to have the same functionality as true real-time text.
> I will change as suggested.
>
> --------------------------------------------------------------------------------------------
>
> 4. In 1. Introduction, last sentence of first paragraph, modify:
>
>> The  native transport for IP networks is based on the Real-time Transport
>>     Protocol (RTP) [RFC4103].
>>
>> to
>>
>> The native transport for IP networks is RFC 4103 RTP Payload for Text Conversation" [RFC4103] based on the Real-time Transport
>>     Protocol (RTP).
>>
>> Reason: It looked confusing with the RFC4103 reference after the RTP abbreviation.
> I will change as suggested, but I don't think we need to say "RFC 4103" in the beginning of the sentence.
>
> So, something like:
>
> "native transport for IP networks is "RTP Payload for Text Conversation" [RFC4103], based on the Real-time Transport Protocol (RTP) [RFC3550]."
>
> -----------------------------------------------------------------------------------------------------------------
>
> 5. In section 1. Introduction, first NOTE, second line there is an unbalanced right bracket.:
>
>> "to the originally introduced concept of a "T.140 data channel"] for"
>>
>> Proposal: either delete the bracket or modify to [T140]
> I will remove the bracket, as there is a reference at the end of the sentence.
>
> --------------------------------------------------------------------------------
>
> 6. In 1. Introduction, the first NOTE,
>
>> Delete "back in 1998"
>>
>> Reason: Irrelevant
> Will be removed.
>
> -------------------------------------------------------------------------------------
>
> 7. In 1. Introduction, number the notes NOTE 1 and NOTE 2.
>
> Will add NOTE numbers.
>
> --------------------------------------------------------------------------------------
>
> 8. In 3.1 third line, delete "(m= line)". The correct term is "media description" that is already correctly used.
>
> In other documents (e.g., BUNDLE) we say "SDP media description (m= section)" on the first occurrence, and later only 'm= section'.
>
> Maybe would could do the same in this document? I do agree that we don't need to say 'SDP media description' and 'm= section/m= line' in every occurrence.
>
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> 9. In 3.1 Use of dcmap Attribute:
>
>> The second paragraph says that the "label" attribute MUST be included, but the next to last line says
>> "without any label" and the example lacks the label.
>>
>> sdpneg says that "label" is optional, so I suggest that thestatement in the second paragraph is modified to not require "label"
> Will fix as suggested.
>
> -------------------------------------------------------------------------------------------------------------
>
> 10. In 3.2, first paragraph, third line, delete "(m= line)".
>
> See my reply to comment #8.
>
> ------------------------------------------------------------------------------
>
> 11. In 4th paragraph in 3.2, change "cpc" to "cps"
>
> Will fix.
>
> ------------------------------------------------------------------------------------------
>
>
> 12. At the end of 3.2, add the following about language negotiation
>
> You sent a follow-up e-mail regarding this this comment, so I will address it in a reply to that e-mail.
>
> ------------------------------------------------------------------------------
>
> 13. In 3.3 Example, first line, delete "(m= line)"
>
> See my reply to comment #8.
>
> -----------------------------------------------------------------------------
>
> 14. In 4.1, fourth bullet point, Deny session,    change:
>
>> "reject a request the establishment of a T.140 data channel,"
>>
>> to
>>
>> "reject a request to establish a T.140 data channel,"
> Will fix.
>
> ----------------------------------------------------------------------------------------------------
>
> 15. In 4.2, second paragraph, change "reduntant" to "redundant"
>
> Will fix.
>
> ---------------------------------------------------------------------------------------------------
>
> 16. In 4.3, add at the end of the current paragraph:
>
> "The user requirements for smooth flow and low latency in text conversation should be considered when assigning a buffer time.
> The default transmission interval of 300 milliseconds from [RFC4103] or lower is recommended also for T.140 data channels."
>
> I will add the text.
>
> Is there a reason why you want to say "text conversation" instead of "real-time text conversation" in this case?
>
> ---------------------------------------------------------------------------------------------------------------------------
>
> 17. Add a new section 4.4
>
>> "
>>
>> 4.4 Loss of T140blocks
>>
>> In case of network failure or congestion, T140 data channels may break.
>> If this happens but the session sustains, it is recommended that a low number of retries are made to reconnect
>> the T140 data channels. If reconnection is successful, an evaluation shall be made if any T140blocks were lost.
>> Retransmission of already transmitted T140blocks MUST be avoided, and missing text markers [T140ad1] should
>> be inserted in the received data stream where loss is detected or suspected and presented to the user.
>>
>> If instead also the session breaks, the break is accepted as end of session and the user should be informed about the unexpected end of session.
>>
>> "
> I will add the text (with some minor editorial changes).
>
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> 18. Add a new section 4.5
>
>> 4.5 Multi-party considerations
>>
>> Implementations should be prepared to accept establishment and use of multiple T140 data channels in order to support multi-party sessions
>> with real-time text. A number of scenarios are available for how multi-party sessions can be supported in the WebRTC environment.
>> Implementations may select any suitable scenario.
> I don't think we need the two last sentences.
>
> Also, in some cases all communication will go via a central server, so there will only be one T.140 data channel towards each participant.
>
> So, maybe something like:
>
> "In order for an implementation to be able to support multi-party scenarios where each participant will communicate directly
> with the other participants, the implementation need to be able to support multiple simultaneous T.140 data channels."
>
>> Presentation should be made so that the source of the real-time text is perceivable and the relative time relations in the conversation approximately presented.
>> The "label" attribute may be used to convey a presentable source.
> I am not sure I understand the "relative time relations" part.
>
> Regarding the source, perhaps extending my suggested text above with something like:
>
> "In order for an implementation to be able to support multi-party scenarios where each participant will communicate directly
> with the other participants, the implementation need to be able to support multiple simultaneous T.140 data channels. The label
> attribute can be used to provide information that helps an implementation to distinguish between the T.140 data channels."
>
> ----------------------------------------------------------------------------------------------------------------------------------
>
> 19. chapter 5, Gateway considerations is proposed to be replaced by the
> following:
>
> In order to not make the e-mails too long, I will address this in a separate reply :)
>
> Thanks!
>
> Regards,
>
> Christer
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288