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

Bernard Aboba <bernard.aboba@gmail.com> Tue, 24 September 2019 22:15 UTC

Return-Path: <bernard.aboba@gmail.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 84DC4120033 for <mmusic@ietfa.amsl.com>; Tue, 24 Sep 2019 15:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 diWsY4I3HQ0B for <mmusic@ietfa.amsl.com>; Tue, 24 Sep 2019 15:15:37 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1346B12083B for <mmusic@ietf.org>; Tue, 24 Sep 2019 15:15:37 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id a22so3529470ljd.0 for <mmusic@ietf.org>; Tue, 24 Sep 2019 15:15:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w6jpH0PvLu+F4Lrhpm/9btYeVQ2NGrPf1MJ8DNtx6pc=; b=WaeoG+O39Rg4KdhqqpnKES6rqP2YfWcs5aQO+tYl/lW/Cc0bz0TNtZ6Ky0xNAgGJlS zPVtXuY3oPxHpO23vQYSVSTixV5lynTJUzDMtjmyb1A0dufLcruT0Bg40AiVQMJvr1Ns suZkRrnBgScGMVrhiLIAzG/Em/2VLQXkn61hd+VDqkUgBxZ/GdKEvchrwh8zSE0iKpOi lBT1vJACwGupTs8tgbSvxSbf8TO1IbjjvGkpyr8Tkwt5Bd/CWw9VDapKaQzWrf9+ne+L jlfHJLJTpMeqbGpALEFXAc1L+JK3rscxQRrN3esQwD1t1+I7ShJCn1VTAboR07PIguIu Cfww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w6jpH0PvLu+F4Lrhpm/9btYeVQ2NGrPf1MJ8DNtx6pc=; b=cSMqwYISQBTauK3mNrZZhpB85/tkDvS6pQ/66dsOhw0rpm0+NADCHhP8WG34bctg+t /URX0712CzSs61Icy8dTSTfoFkIYSPDaPnvNoZgzpE8w/s08ust+3xvcu6OH9v6lU0F0 scH8b4nU7wTJZvzlRRjnjz0uo1m74jYGD5Q223QH1NeQf3/4Vj3bqc7K30N6VyMmUu0i NAVqvYSRUQKDglj0kdJUt6B6aheDnIc/9eQ2sMwwxu3OMPP6pffwaavIJ77anKI2j8p9 Xc/HWAwWmDpZji6V5OJF9/HMGN6D8iDjSKF75Ro54rCliwbg3jc7d8nJmW87c0LCfW64 9s4w==
X-Gm-Message-State: APjAAAX+vK6S1kO5NBeVoUvNqwPkLN9nL9njl55UqbLMnVZPowFQM+LN 8Sx2h9fntDTNZAar2jPcb8asc2LT3gxUtY6xQ/8=
X-Google-Smtp-Source: APXvYqzUsQf51wgiVBrRUv4a0Vod9xqvS2M0GM93SPcAzRYTKP1sOPJwzcCfJhDtZDDfN5nh0wybBHIqDHbgKGnMGTY=
X-Received: by 2002:a2e:9185:: with SMTP id f5mr3581774ljg.235.1569363334716; Tue, 24 Sep 2019 15:15:34 -0700 (PDT)
MIME-Version: 1.0
References: <CAOW+2duiD8ZTDQpzupfC9S7tp7k6Xm5K2vA+643RMTpkDCnsMQ@mail.gmail.com> <HE1PR07MB3161640EC7A7269FE3A0D11993840@HE1PR07MB3161.eurprd07.prod.outlook.com> <VI1P193MB06698BA67FA8D8C5050BF10CFB840@VI1P193MB0669.EURP193.PROD.OUTLOOK.COM>
In-Reply-To: <VI1P193MB06698BA67FA8D8C5050BF10CFB840@VI1P193MB0669.EURP193.PROD.OUTLOOK.COM>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Tue, 24 Sep 2019 15:15:22 -0700
Message-ID: <CAOW+2dv1YQ-UtXBWj5RZ=FDGvGKmjV+mwjQH4TAyFsbe75ivEQ@mail.gmail.com>
To: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Cc: Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000016e11b059353e07f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/IqJPSiM57M7Tox3ln0HSlzfriCo>
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: Tue, 24 Sep 2019 22:15:40 -0000

Gunnar said:

"A concern though: If the reliable channel breaks because of bad
conditions, can we then really know on both sides what has been transmitted
so that if we get a successful reconnection we can avoid resending already
received text?"

[BA] Without some additional application-layer mechanism, I think the
answer is "no".

On Tue, Sep 24, 2019 at 3:08 PM Gunnar Hellström <
gunnar.hellstrom@omnitor.se> wrote:

> Hi,
>
> 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.
>
>
>
> [GH] I agree with Christer. There is a risk that during very severe conditions, the reliable SCTP association makes a number of retries for up to 30 seconds and then breaks,
>
> But the chance to get understandable text through in such conditions by sending in an unreliable channel with redundancy is probably not much higher. And it would require to for example use RTP and RFC 4103 on top of an unreliable data channel, a complication I would not like to introduce.
>
> I made a bit more comments on this on August 21.
>
>
>
>
>
> ---
>
>
>
> >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.
>
>
> [GH] The Stream-ID can be seen as "an SSRC", and the Label can be seen as a CNAME in one direction. Sequence number and timestamp are usually only used on transport level, and something similar is likely used in the reliable data channel transport, but not reported to the application.
>
> A concern though: If the reliable channel breaks because of bad conditions, can we then really know on both sides what has been transmitted so that if we get a successful reconnection we can avoid resending already received text?
>
>
> Regards
>
> Gunnar
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>