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

Christer Holmberg <christer.holmberg@ericsson.com> Sat, 24 August 2019 10:04 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 CAF451200E3 for <mmusic@ietfa.amsl.com>; Sat, 24 Aug 2019 03:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 FkBPoWDSWUUJ for <mmusic@ietfa.amsl.com>; Sat, 24 Aug 2019 03:04:42 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130080.outbound.protection.outlook.com [40.107.13.80]) (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 5AEA112003F for <mmusic@ietf.org>; Sat, 24 Aug 2019 03:04:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ETBxbE6/fU4kxXSzF0OqlaCqNj2FB0tc5pqRojYUBagY4Fabk8344Uo/wpEs+pWebolWbO3G+f6NYfbLVCLlN/C4/kkItB6GQ2R5QmeOwifbfqLtt1eqOmjZfbqQialM9d9ySZz8PgiwEGgpOIP83TBlOEcutiis1K54y+F10IHrtjsUSemVzk02G54X9uup+wadkP3xKyuNBZWqiJEuIAHT5eIRHrtbUt6vmEWE2VNCJ4J2EH4XKAvkjiMADAXkLGDLVnOTRFhUapKQGGwOq1Ryg9xNtAW1EepPZj9REsOteINNJEGEnYYqKjrzn7yt3Gf9iUvw2lJMleZSQ9W5GQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oequbHx3nblnLtHP3W/zExU1YZJM50/AT1tRlEukr3Y=; b=Rz8Jnd4SHf/1iCVhzU6PIdpNqFBchd7KsvXah/ti9slwa2Iv1zaxfApHCHQUtyCSFKqcJMVnTBDW/UnF1NkxufbcfmFr+qTzjgYHyk+lpCu/eSUGFi35G5nfDnTRgGIFKd0WBrtVgLH7YHtqRXvH/ILaAAiA5jncTyPNn28+d9c8UzFWp526flKurXdnXyYjE+TW/5c+PwKBdGj7jVvt16kupY22zQFOEMaHoGRZNjRQk7l7BMYiTPcHEfamtmAvBRA9yz5gJeGpz0kveOQj9UJy6ebhJvj2atxstdlas5PAXu7Ahg0H+xcFpifJ5xCHCFxBIw0hgOscKDbWuScGgQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oequbHx3nblnLtHP3W/zExU1YZJM50/AT1tRlEukr3Y=; b=QrbmRPx0KA/DVMgBtolHNOH1luAUda/658mb7m5aubBPWyzHPptrSn0XKeT5Rb4x8yWssUPrfKnvbRmCFLjLJF2wrwj0DBglHWlPU6TNNgj08Nfq1oKUabikwDu5fs/jwjrf8bgevksH+yhj/BQB7uTUxI90Hb8oYpXgDsBUAak=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3482.eurprd07.prod.outlook.com (10.170.247.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.13; Sat, 24 Aug 2019 10:04:39 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::f0a1:2199:7816:ff8d]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::f0a1:2199:7816:ff8d%6]) with mapi id 15.20.2220.009; Sat, 24 Aug 2019 10:04:39 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Gunnar Hellström <gunnar.hellstrom@omnitor.se>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Draft new: draft-holmberg-mmusic-t140-usage-data-channel - modification proposals
Thread-Index: AQHVWgWIDYz2E2u4JkiY8ng0BW5GzKcJ/fYA
Date: Sat, 24 Aug 2019 10:04:39 +0000
Message-ID: <HE1PR07MB3161A9A0C696B9636BBD380C93A70@HE1PR07MB3161.eurprd07.prod.outlook.com>
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>
In-Reply-To: <6fcf46a6-544d-027c-97c7-5c0e08caa555@omnitor.se>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com;
x-originating-ip: [79.134.118.162]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 886b07b1-dd07-442d-095e-08d7287a7a36
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3482;
x-ms-traffictypediagnostic: HE1PR07MB3482:
x-microsoft-antispam-prvs: <HE1PR07MB3482CB95CBE6DFF008BA7FAD93A70@HE1PR07MB3482.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0139052FDB
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(376002)(366004)(136003)(346002)(199004)(189003)(2906002)(52536014)(14444005)(8936002)(256004)(186003)(478600001)(3846002)(6116002)(6436002)(81156014)(81166006)(76176011)(110136005)(561944003)(9686003)(476003)(74316002)(7696005)(66446008)(64756008)(66556008)(99286004)(55016002)(66066001)(76116006)(66946007)(66476007)(7736002)(316002)(25786009)(2501003)(305945005)(102836004)(5660300002)(8676002)(486006)(26005)(86362001)(6506007)(11346002)(53936002)(33656002)(44832011)(71200400001)(71190400001)(446003)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3482; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: B0a5D19lbjSXJ3IBEg16cEFMBUQ0qc8Lc1OOdeYYhrufSx1gr5pzOi1la1ZGPjnCXLqIuxIG2dT0T3uD0M7P2PaxNbfdyW0lX1NboB19tKROfu2I7h6Ggj8jqdOXVtIK0EFxZ90wDhwL7uwQQlwWYLCDMQvU2DVkjUFN7VQlWyOB0VAzAjBdVwjb0pJNmzlzMPzwk5d3tXeFqNpQkj9jXbgUrXs06YZRBFpsMy+YUvQhN6tW6++AJxvzQZsO4bYwP09a9X2WeNeLwVXjt+d9YAfP8OS0POQWZuczqe3hg+aq9jgdCp+diOtP56C1O/c2j7+Jyc8gFHG5cFYZ5ltCxVKKrAu1gPRFBcFj9TPZ1O84DFsrQn0NbRc7aagl/CLyjiBv6BHae9s0n9W5ATfUbc8584GLu7Xk5v6AIYiOIVA=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 886b07b1-dd07-442d-095e-08d7287a7a36
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2019 10:04:39.4659 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8wb69qIBK7XCOBVaikCFrcwuMbw3OG88gfWOoxIUwoHGSwiexOcRETbFpdz/xb4segetiLIleSW2wST5qeetlG7oLXJTuOm536HtQQG3fbk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3482
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/CKIVGXGejE7CfcdfxUxWSBl_rLc>
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: Sat, 24 Aug 2019 10:04:46 -0000

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