Re: [MMUSIC] T.140 in Data Channel scenarios

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 25 September 2019 09:26 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 8614B120164 for <mmusic@ietfa.amsl.com>; Wed, 25 Sep 2019 02:26:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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, 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=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 u_QeEHMAOLCr for <mmusic@ietfa.amsl.com>; Wed, 25 Sep 2019 02:26:32 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60070.outbound.protection.outlook.com [40.107.6.70]) (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 BD75D12011A for <mmusic@ietf.org>; Wed, 25 Sep 2019 02:26:31 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MzUzahNHc5RR4DFq7az1ejNzgiDKkQSyCHxWRUZxZ631/JE2+8sgAH8c2vwGVz9aiYTdDcVjreC34ZuFHNCUX0wQD1GwzXubFFy3x5Nmg8u89xGbkzSNQo4YPKPG97WB5MqKVa6JEymZPowOJWJl6mKpuGmXB/6j7pkMsfRrakkOJ/C95hMKdRx9VIEfbrmHiNUwe8g/Kbabq4/KEyITXs7rLnD8vwZqZTbQ0iLxDv3HZjVfInH9zAjKE2IOkCbaM2nVRWe0JS99NY+0Im+63YQTBqz4wXl4RTl9cimubofV8J92+JWVWx7rvOhm9YDoV9bPin43AznTKXfDfODvew==
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=qwNzBLWzRuhTIn/58YUjMkJfCwuosPWh0+bOXBwyIHc=; b=W4NXQtmVy/NbAZGPuwmT9Fxapurxcxcp4+JoqYaoMlB7FmvHm5ovzikAHuo4po6OPtOokgDzEYvFTekCR68XCfyb4aqkOzYMReU7xSNCnHt3XsFNnxrGVp8S/BEj8Xkx9VqQPrgbqD7Ii9KyhjFiogE5Huu5DiwJyKs7GS1LiTZkKGM7la5Ee07xrQmE56FSsYSpKguP259wpOQWF8A+hVjKYmfkTq1zPXEO+oacLlhyzc+MG+LCtG+DKVWXe8dnAgA+kmfrpWkzjfCYca4s4qgvY12d0mrzfU1HiHOnalGkid1zGN5mwMu5WaRy3iLhp9jJDjDinnG/ZElz46lkgA==
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=qwNzBLWzRuhTIn/58YUjMkJfCwuosPWh0+bOXBwyIHc=; b=ZTCGA35aXQnXYM81BQwDpizQkjyaqU4CPrm3I5fMGfD25SRwZjVnvMa2EzfXuhWZHUsnnMrqCgZzAq7MiLM7uHe4LiYAtbCDZP4zuarxqKgnCZM8DbM3OElaUUCJxwMY3pk/8NMu2M/w7/MBEobqfFEgucx4jt6xH6dl4ZgL1UU=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4170.eurprd07.prod.outlook.com (20.176.164.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.11; Wed, 25 Sep 2019 09:26:29 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::14d0:5c4f:26b7:b6e9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::14d0:5c4f:26b7:b6e9%3]) with mapi id 15.20.2305.013; Wed, 25 Sep 2019 09:26:29 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
CC: mmusic WG <mmusic@ietf.org>
Thread-Topic: [MMUSIC] T.140 in Data Channel scenarios
Thread-Index: AQHVcwg397T7HkcM4k22ZCkGGd5UwKc7OW8wgAAjmwCAAPXOAA==
Date: Wed, 25 Sep 2019 09:26:29 +0000
Message-ID: <AB3B3CB9-1CF9-49C6-AC4F-8696E15E9EFE@ericsson.com>
References: <CAOW+2duiD8ZTDQpzupfC9S7tp7k6Xm5K2vA+643RMTpkDCnsMQ@mail.gmail.com> <HE1PR07MB3161640EC7A7269FE3A0D11993840@HE1PR07MB3161.eurprd07.prod.outlook.com> <CAOW+2duN+PhXRvVRQRejWzkcA7-Ah8M=Ligy7RrywDVELQsauQ@mail.gmail.com>
In-Reply-To: <CAOW+2duN+PhXRvVRQRejWzkcA7-Ah8M=Ligy7RrywDVELQsauQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1b.0.190715
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com;
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 456201c9-3711-4685-ff5f-08d7419a7244
x-ms-traffictypediagnostic: HE1PR07MB4170:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <HE1PR07MB417055A9075FAB36736410AC93870@HE1PR07MB4170.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01713B2841
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(136003)(366004)(39860400002)(346002)(189003)(199004)(51444003)(51914003)(11346002)(2616005)(66066001)(229853002)(6436002)(86362001)(478600001)(66476007)(64756008)(6246003)(476003)(44832011)(66446008)(6306002)(81156014)(81166006)(53546011)(5660300002)(7736002)(236005)(102836004)(186003)(6512007)(2906002)(316002)(26005)(606006)(58126008)(3846002)(6116002)(66556008)(446003)(71190400001)(486006)(54896002)(14454004)(4326008)(76176011)(99286004)(76116006)(66946007)(14444005)(25786009)(33656002)(6506007)(256004)(71200400001)(6486002)(8676002)(6916009)(8936002)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4170; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: oNjBAVjLkYoCASQHhreHRDJeQw1EAr0O7E7t632ZymnR0MmSbYn4C+xk1V74Q3BM7IDArtGabvSKZd17wu+5AqiOd9ilwNRutVriT+meObjZXoim7HDPdF2qOiBy3kl2/6CXjpSO+kHviHBGMp85OWgDqtKJnum6YdhtKMtGWw84Ly9uN4T2GkN7Sk5ZOzoduFOqXCanbixExFw4rRZTCFKVy6dub+A++pQn9h2eTQu+YNvPlEqwbWhjEVlQn4VZrUpq+pcUv+l8qxIp57oaR152WB1QnoQy8vWR+aK+9yVbDagew0nEfIGa7g3L++szIeSrYzR+W++cNktAa/uxvjIRz6EWjA4+lOuVYTPBCkHrJvMcV6iRU5tkVe8CLDXQ4oBbHwP6FQg/I5khBW1Lx9JTNqBZS7J4Qt2eTlcaYJ4sTNsDTORDd0NbcDFHyUtT1PSSJnl3DF7DcOFWAGcxmg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AB3B3CB91CF949C6AC4F8696E15E9EFEericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 456201c9-3711-4685-ff5f-08d7419a7244
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2019 09:26:29.2339 (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: iUMsnSY7sadAibujBrLyosiigh9eJs6Ai7l6zQAsn2CBBmvBlW/p1wWzDVlnSEj4KXJCmf/rXLaaU1ROPcYSQrINPbxUofVjEvSdxGiuejc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4170
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/qJc3133_z1ghzOtBPUjDR8Q-fiE>
Subject: Re: [MMUSIC] T.140 in Data Channel scenarios
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, 25 Sep 2019 09:26:44 -0000

Hi,

> Thanks for the explanation.  Would there be a way for some of this to make its way into the document?
> I think that would make it easier for the APA to review.

What about the following note below the table:

“NOTE: T.140 does not provide reliable and ordered transmission of T.140 data.
Instead, T.140 requires the transport channel to provide real-time text without
duplication and in original order. When RTP based transport is used, the RTP sequence
number is used to detect packet loss and out-of-order packets, and a redundancy
mechanism using the RTP timestamp is used to achieve reliable delivery of T.140 data.”

Regards,

Christer








Christer said:

"T.140 requires the transport mechanism to keep packets in order, and without duplication. When using RTP, the sequence number is used to detect out-of-order packets and loss of packets. You don’t have that mechanism in a data channel, and T.140 itself does not contain a sequence number.



When using RTP, reliability can provided by sending of redundant data, or by using FEC. FEC is RTP-specific, so you can’t use that on a data channel.



I don’t think the redundancy mechanism can be used on the data channel either, because it uses the RTP header timestamp.



And, you can not re-transmit T.140 text on a data channel (T.140 RTP packets are not re-transmitted either), because the receiver will not be able to detect it (again, because T.140 does not contain a sequence number).


Of course we could have defined an “envelope” for the data channel T.140 text, with sequence numbers. But, the idea was to simply send the T.140 text as the data channel itself provides delivery and reliability."

On Tue, Sep 24, 2019 at 1:12 PM Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
Hi Bernard,

Gunnar will probably be able to give a better answer, but below are some comments from me.

>At the W3C TPAC 2019 meeting last week, draft-ietf-mmusic-t140-usage-data-channel came up as part of a discussion of Accessible RTC Use Cases:
>https://www.w3.org/WAI/APA/wiki/Accessible_RTC_Use_Cases
>
>Here are a few of the questions that came up.
>
>Section 3
>

>       +--------------------------+-------------------------------+

>       | Subprotocol Identifier   | t140                          |

>       | Transmission reliability | reliable                      |

>       | Transmission order       | in-order                      |

>       | Label                    | See Section 4.1<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-4.1> and Section 6<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-6> |

>       +--------------------------+-------------------------------+

>

> Are there any situations in which unreliable or partially reliable transport might be appropriate?

> For example, some participants envisaged scenarios in which low latency communications might be

>  desirable, such as in emergencies, and questioned whether it might make sense to use the maxPacketLifetime

> or maxRetransmissions parameters.

>

> So there was a question about whether it might ever make sense to support an unreliable data channel (possibly with redundancy).



T.140 requires the transport mechanism to keep packets in order, and without duplication. When using RTP, the sequence number is used to detect out-of-order packets and loss of packets. You don’t have that mechanism in a data channel, and T.140 itself does not contain a sequence number.



When using RTP, reliability can provided by sending of redundant data, or by using FEC. FEC is RTP-specific, so you can’t use that on a data channel.



I don’t think the redundancy mechanism can be used on the data channel either, because it uses the RTP header timestamp.



And, you can not re-transmit T.140 text on a data channel (T.140 RTP packets are not re-transmitted either), because the receiver will not be able to detect it (again, because T.140 does not contain a sequence number).



Of course we could have defined an “envelope” for the data channel T.140 text, with sequence numbers. But, the idea was to simply send the T.140 text as the data channel itself provides delivery and reliability.



---



>Lost information (compared with RTP)

>

>We had some questions relating to information "lost in translation" between realtime text

>and data channel.  This includes aspects of the RTP header, including SSRCs, timestamps and sequence numbers.



Yes, that information is lost.



There were some discussions about including SSRC somehow, in order to support conferences where a mixer uses a single data channel for text received from multiple remote users, but we decided that it is outside the scope of this draft.



Regards,



Christer