Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Wed, 06 November 2019 21:04 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 2561F1200FF for <mmusic@ietfa.amsl.com>; Wed, 6 Nov 2019 13:04:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=omnitorab.onmicrosoft.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 ldDJtlhpAAl6 for <mmusic@ietfa.amsl.com>; Wed, 6 Nov 2019 13:04:30 -0800 (PST)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50094.outbound.protection.outlook.com [40.107.5.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99BD0120072 for <mmusic@ietf.org>; Wed, 6 Nov 2019 13:04:29 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j2nAwx/6TSG5WY6Hr+JPRmZUBfPNrVWp6UCor41At6lk0Y7CkHZMoKp1vPN3UfEeURE45CzmRZAe62atijc/eb7GelmnKosnIBY47QYbOeo/JX25kpX+BsMYMNXgBGMngLyfesL+CzLdhodN82jEns95N+C2GMTKUWTkOhgDlEGNeYGviL6nOMFbkFF16ejLzTwuXsqnyPCDFajNrJU+VhtVdPAg7yvvDT7P9P7qtO6b6aY6WtaN1+JgL+q17ifpbHnjheH/t1b1+k825osELquKi4dGdTWGZe3EykdmME+3lWapVn+IvkNJkpw0cvgfbq9BDrVoLVimi1QQwiUAnA==
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=r+XLP2yH9ppDT7Ou+TVckIiLRWNGaqBZEvb1tBxG8UE=; b=lif+zagZ14+NPWIzb/tVoVJWjllrYCPM9F/hM5rUt4xf/rcwiCNpRb+9Ug7g5foji/6mgemVylZ/MMtc7FD8RUnntf3NwY7wNcnF9SXgglqOTtlAzkbq5k6tb/q+dvoShXv6cUjXuDhYK7c3pFg0gYC3ZFMTE8o+zETQs/H4bHx8l9l3UTAgR8RKlsgw9uT/AWictQjG4K9lRFx5HdrDGEoVieZOVOaoByvVVIKX6Pt7qooZgy5Auej+kIZ4PMO0EI/6IX0niOlkQcrjL+4C3XyTNNGe6DU66dkcBEXhHHZ5ApZ0S9g43Qs44GBEPkT5jI+ZxJF8GWYwhgJarM5fRw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=omnitor.se; dmarc=pass action=none header.from=omnitor.se; dkim=pass header.d=omnitor.se; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=omnitorab.onmicrosoft.com; s=selector2-omnitorab-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r+XLP2yH9ppDT7Ou+TVckIiLRWNGaqBZEvb1tBxG8UE=; b=pAmUPeUxHGEmqU3GUbJeYqmMauQNTLLNJBA48hGJ8whH8T8EDi0osT9/F3LJNcHKX/CyFxzF5uzxHuz9JvtJflBl53nQqSWs8O+HUIyeJ8zO98dvLqD+XXSzCgIXHa0ba0+qXLSdY+TQ0/XfFfJeQIQ4MovgZBSClzNCgm0emYw=
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM (10.186.178.76) by VI1P193MB0352.EURP193.PROD.OUTLOOK.COM (52.134.122.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20; Wed, 6 Nov 2019 21:04:25 +0000
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::1dfd:c8d1:a788:87cd]) by VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::1dfd:c8d1:a788:87cd%7]) with mapi id 15.20.2430.020; Wed, 6 Nov 2019 21:04:25 +0000
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Bo Burman <bo.burman=40ericsson.com@dmarc.ietf.org>, "mmusic (mmusic@ietf.org)" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments
Thread-Index: AQHVk909yEtpzH2MKEqkZmDSG+/rpKd9K6IAgACj3A+AAHGsCYAAFbG3gABHZYD///41AIAAB1WA
Date: Wed, 06 Nov 2019 21:04:25 +0000
Message-ID: <a4d86cf8-7179-a52e-1b0c-e08c45ff6126@omnitor.se>
References: <31B83060-1653-48A1-AB78-9D2418B49CC6@ericsson.com> <5742e425-788d-7d10-0e68-0a75bea74f3a@omnitor.se> <HE1PR07MB31619BBC3A73260C14CC693693790@HE1PR07MB3161.eurprd07.prod.outlook.com> <VI1P193MB06698D287FB68B4DDE435E98FB790@VI1P193MB0669.EURP193.PROD.OUTLOOK.COM> <HE1PR07MB31610CA6717330B5823EC72F93790@HE1PR07MB3161.eurprd07.prod.outlook.com> <c45c5029-72b2-d25f-4a3f-bc1d1c445a1f@omnitor.se> <HE1PR07MB3161924E0BFF775E35376B4893790@HE1PR07MB3161.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR07MB3161924E0BFF775E35376B4893790@HE1PR07MB3161.eurprd07.prod.outlook.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: GV0P278CA0003.CHEP278.PROD.OUTLOOK.COM (2603:10a6:710:26::13) To VI1P193MB0669.EURP193.PROD.OUTLOOK.COM (2603:10a6:800:159::12)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunnar.hellstrom@omnitor.se;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [83.209.227.4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7f0243a5-f609-423e-efc7-08d762fce79c
x-ms-traffictypediagnostic: VI1P193MB0352:
x-microsoft-antispam-prvs: <VI1P193MB035286D9F88D20340B9C8E78FB790@VI1P193MB0352.EURP193.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02135EB356
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39830400003)(376002)(346002)(366004)(136003)(189003)(199004)(66476007)(85182001)(19627405001)(86362001)(71190400001)(2616005)(486006)(71200400001)(476003)(256004)(386003)(66066001)(186003)(7736002)(6246003)(26005)(11346002)(446003)(6506007)(36756003)(53546011)(85202003)(14454004)(99286004)(508600001)(25786009)(561944003)(14444005)(31686004)(316002)(31696002)(110136005)(76176011)(6512007)(236005)(6486002)(229853002)(2906002)(6436002)(52116002)(3846002)(6116002)(54896002)(5660300002)(66446008)(64756008)(66556008)(66946007)(105004)(66574012)(102836004)(8676002)(81166006)(81156014)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P193MB0352; H:VI1P193MB0669.EURP193.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: omnitor.se does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: NPOVRGf2Um+ZRc8r+sp/wQYVG/xVyfmX1FAm499y1CLt5mC5p7Sb/c2AT91s7j2AY6tqW9Gu6OuUWbiyzfpDcqgPrfhqrmDfxeaSJBq8SWvIv9cFB78apV9K8qaAve6ppasoWSG0ysIAXrdFv7w796NNWaoH3s9jfPl0fANJZrfWS3JxpSHJEMT+BRdhxlM6jv7pC+7lG6l0SHjpTKxTc3T1UPzcvuzHxLnU6igaw1ZGFIST9ys9P1FzDlAueDGCHvzzhHaUsQX3G0ZI1Txaj0lE2WlgrCES7SrEQ1nWajWgLZp226UfK0Gpb3zUsvFgggJq6ez+Yo8VSK6HSHSsFc/76cF+DPCPiW80xRotJWoSFsdI/MLyFYunbMy4Mc+PCdNgqK+02sEt6fifQl+DMGH2/EPsbUVnc/BqhABTMrUnC3o4UkX+K5XJIKYPA9SS
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_a4d86cf87179a52e1b0ce08c45ff6126omnitorse_"
MIME-Version: 1.0
X-OriginatorOrg: omnitor.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 7f0243a5-f609-423e-efc7-08d762fce79c
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 21:04:25.6254 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2df8b35f-363f-46b8-a0d1-ee9b1723225b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: sn0NyjQywkqB6RquyIvC4frJ3nMxeKfcKc/XhSvMyx0xoO5c4TwCWg7HdM60n6uqhoo49evx2oc4LFu1alRx2y/KwxkKnA29isaY+UsxYhg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P193MB0352
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/njEV9XuR8ASkJrqiqOwgzpsACGs>
Subject: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments
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: Wed, 06 Nov 2019 21:04:35 -0000

Den 2019-11-06 kl. 21:38, skrev Christer Holmberg:
Would'n these inline IRC style labels be considered protocol extensions?

No, in my view this would be done by mixer actions on the media stream, by inserting a line separator and an IRC style participant label in text format.


The receiver just presents it according to current T.140 text presentation rules.



It is similar to what a video conference mixer does when it composes a combined picture of a number of participants and code it as just one picture.


Regards,

Christer

________________________________
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se><mailto:gunnar.hellstrom@omnitor.se>
Sent: Wednesday, November 6, 2019 9:44 PM
To: Christer Holmberg <christer.holmberg@ericsson.com><mailto:christer.holmberg@ericsson.com>; Bo Burman <bo.burman=40ericsson.com@dmarc.ietf.org><mailto:bo.burman=40ericsson.com@dmarc.ietf.org>; mmusic (mmusic@ietf.org<mailto:mmusic@ietf.org>) <mmusic@ietf.org><mailto:mmusic@ietf.org>
Subject: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments


Hi,

Even if I accepted to delete the last sentence in section 5 on multi-party, I want to propose a solution that might better address the original issue 5.


So, this is a proposal for new wording of the last sentence in 5, as a solution on issue 5:

"Conference mixers that use a single T.140 data channel
   to transmit real-time text towards clients might however without any protocol extensions produce a limited functionality multi-party RTT presentation in one display area. Only one source at a time can be presented in real-time, but switch of source of text to display in real-time can be made automatically by the mixer and at suitable points in the text streams. Sources could be identified by inline text labels in IRC style. This presentation style does not meet all RTT requirements and if used, should be a temporary fallback method for conference-unaware clients."


This wording is a self sustained description on what is possible and would also match better the recently revived work on multi-party rtt.


Regards


Gunnar




Den 2019-11-06 kl. 17:29, skrev Christer Holmberg:
Bo, are you ok with the proposals?

Regards,

Christer

________________________________
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se><mailto:gunnar.hellstrom@omnitor.se>
Sent: Wednesday, November 6, 2019 5:16 PM
To: Christer Holmberg <christer.holmberg@ericsson.com><mailto:christer.holmberg@ericsson.com>; Bo Burman <bo.burman=40ericsson.com@dmarc.ietf.org><mailto:bo.burman=40ericsson.com@dmarc.ietf.org>; mmusic (mmusic@ietf.org<mailto:mmusic@ietf.org>) <mmusic@ietf.org><mailto:mmusic@ietf.org>
Cc: 'mmusic-chairs@tools.ietf.org<mailto:mmusic-chairs@tools.ietf.org>' <mmusic-chairs@tools.ietf.org><mailto:mmusic-chairs@tools.ietf.org>
Subject: SV: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments

Christer,
I agree with your proposals.

Regards
Gunnar

----------------------------------------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se<mailto:gunnar.hellstrom@omnitor.se>
+46 708 20 42 88
________________________________
Från: Christer Holmberg <christer.holmberg@ericsson.com><mailto:christer.holmberg@ericsson.com>
Skickat: den 6 november 2019 09:58:30
Till: Gunnar Hellström <gunnar.hellstrom@omnitor.se><mailto:gunnar.hellstrom@omnitor.se>; Bo Burman <bo.burman=40ericsson.com@dmarc.ietf.org><mailto:bo.burman=40ericsson.com@dmarc.ietf.org>; mmusic (mmusic@ietf.org<mailto:mmusic@ietf.org>) <mmusic@ietf.org><mailto:mmusic@ietf.org>
Kopia: 'mmusic-chairs@tools.ietf.org<mailto:mmusic-chairs@tools.ietf.org>' <mmusic-chairs@tools.ietf.org><mailto:mmusic-chairs@tools.ietf.org>
Ämne: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments

Hi,

---

3) In section 4.2.1, it says that “If the 'fmtp' attribute is not included, it indicates that no maximum character transmission rate is indicated.  It does not mean that the default value of 30 applies”; >why is this deviation from RFC 4103 chosen? Does it introduce a risk for interoperability problems with systems that also doesn’t use fmtp but interprets it as maximum 30 cps?


Gunnar?

[GH] I don't know why this deviation was chosen. But I have not commented it. You are right that it may introduce an increased risk for interoperability problems. But RFC 4103 has a precaution. In chapter 6, where the cps is introduced, it is said:
"

   receivers of text/t140 MUST be designed so they can handle temporary
   reception of characters at a higher rate than this parameter
   specifies.  As a result malfunction due to buffer overflow is avoided
   for text conversation with human input."



(the reason for this note is for backward compatibility with RFC 2793, the obsoleted predecessor of RFC 4103, so it is not exactly our case, but still valid.)

We have discussed the risk that implementations may not implement setting or reading the dcsa attributes because of the complexity to do so alongside with the WebRTC API. That situation may cause a situation where a sent cps parameter is not obeyed. So the case is quite similar to the case in RFC 4103, and applications would be required to prepare for handling temporary reception at high rates.

The intention of T.140 is to handle real-time text conversation between humans. Huge cut and paste chunks of text cannot be required to be handled rapidly. The highest speed human interaction would be with speech-to-text applications. A very rapid speaker may produce 200 words per minute. That is 17 characters per second. The speech-to-text applications often makes corrections by long backspaces and resendings. That may add 10 characters per second in the total. That results in a practical need of up to 27 characters per second for one stream.

This calculation shows that for two-party calls, it would not hurt to use the same convention regarding cps default as RFC 4103 (30).

For centralized conference solutions with just one data channel from the conference server discussed in section 5.5, the need would be a multiple of that rate (27) corresponding to the number of simultaneous text senders. In well managed conferences this multiple is very close to one.

The figures above are extremes. Currently most use of RTT is typing at maximum speeds of about 7 characters per second.

Leaving the default to unrestricted might attract some misuse by implementations or users trying to use the T.140 data channel for data transmission of data totally different from the intended real-time text.

Conclusion after all this discussion:

Neither leaving the default to unlimited, nor changing to a default of 30 cps as in RFC 4103 seems very critical. Any solution will do.


[Christer] I am pretty sure IESG would ask about this too, I suggest that we change the default to 30 cps.


---


​5) In section 5.5, in the note, it says ‘…with limitations in real-time performance and presentation style’; I think it would be helpful to briefly elaborate on what type of limitations would be >expected and why.


I think it is explained in the other text of the section. For example, using a single data channel without any protocol extensions would not allow to separate the sources etc.

[GH] I think we can offer a bit more text at the end of the note to clarify. How about this:

"T.140 shows two examples of presentation layout for real-time text, one being column oriented, with one column per participant, another being arranged in one column with labels identifying the beginning of text from each participant and text from a number of participants received and placed in places corresponding to these different participants. With a conference mixer using one text stream and not applying any presentation protocol extension would only be able to produce a string for presentation in one column, including a source label in the beginning of text from one participant and only show text in real time from one participant at a time, shifting real-time presented participant at suitable points in the text stream. (end of phrase, end of sentence, line separator, long delay etc.). This presentation style may not be preferred by the user and it may cause delay before presentation of text from other than the currently presenting participant."

Pew, maybe too long and detailed....


[Christer] Or, could we simply remove the last sentence ("Conference mixers that...")? The 1st paragraph already says why separate channels are needed, and the note says that future extensions may allow usage of a single channel, so I think it is pretty clear that using a single channel without any such extensions would come with limitations.


---



6) In section 6, bullet “If the gateway detects or suspects loss of data on the RTP stream…”; shouldn’t it await possible redundancy first and missing text marker is inserted only when the used >redundancy is not capable to repair the loss?


Gunnar?

[GH]The intention was that it would mean "after using possibly received redundant data".   You could interpret "loss of data" to mean that (instead of "loss of packets"), but let me try an improvement: "If the gateway detects or suspects loss of data on the RTP stream, after use of possibly received redundant data, …"


[Christer] What about?


"If the gateway detects or suspects loss of data on the RTP stream, and the lost data has not been retrieved using a redundancy mechanism, the gateway SHOULD insert the T.140 missing text marker [T140ad1] in the data sent on the outgoing T.140 data channel."

---



12) In section 11.1, in the [T140ad1] reference, is “aEUR” really part of the name? The name I find listed on the ITU-T web is “ITU-T T.140 (1998) Add. 1 (02/2000)”, and the title in the document >itself seems to be “Protocol for multimedia application text conversation; Addendum 1”.


Interesting. There is no "aEUR" in the XML file, so this seems to be something created by XML2RFC.

The intended title is:

        Recommendation ITU-T.140 – Addendum 1  (02/2000), "Protocol for multimedia application text conversation"

I will fix it.

[GH] I chased a number of such occurrences earlier. I think it was because your editor inserted an unusual slanting quotation mark. Note that there is also a double quotation mark on the third line of the same reference.


[Christer] I will double check.


---


Regards,


Christer



--

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se<mailto:gunnar.hellstrom@omnitor.se>
+46 708 204 288

--

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se<mailto:gunnar.hellstrom@omnitor.se>
+46 708 204 288