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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Wed, 25 September 2019 21:39 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 45C8D12004E for <mmusic@ietfa.amsl.com>; Wed, 25 Sep 2019 14:39:21 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.001, 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 j_msWmQ_EEGb for <mmusic@ietfa.amsl.com>; Wed, 25 Sep 2019 14:39:17 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70122.outbound.protection.outlook.com [40.107.7.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A006D120026 for <mmusic@ietf.org>; Wed, 25 Sep 2019 14:39:16 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EyFq8novyiYxTurZSq5n0lIPAZl7CRqsGiOUNtnKBtqUTPUd0yr+Qn/auC8P+ab1SkV37ttn9WgfDWfPIwk/JDnY7ozZte1X9TikI0wAe1B8/icdVNiH8DResyYGJIhon47fONXd/qSKfYSfYaLoMiXk1saOYmaFJDC/nG5L/CcM5T+xnYedvD7V73Fr2pTp627BGK3OSLaM3k3geqVirErYHiHcgoGLaB2IxhyzwAdC20z59qeonXgJx1zvcIDb7gzKjp9BZp19qPb23JCm2wjMKZ9iwkdSXf22l1TQSZAlUkAleu3CtntmLOZje7tUstPbC9t2ifMTdHRm/0xyHg==
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=32seFceQ/MrQHIgbdnk5C/k5saF+Ju8VaY+/6iBw+68=; b=nHdIouf7wuIn1/vJenb2fZt0PxkWT3WH2mm2Okpp4AwCrbbHEhWl5hcXaZfeM/6ISvDMHwWpC1RcuYni6xGU9Gdaot3J/xxEZXugZajtFhjwwhxxRaA3IJVfUB70wRTjZnHijV6vxURcmzYOjQwpmEU0N4dvh0L3CGbhiwtd8JqFmot2KKP7ryJnFksOt2N4JJ+7g5my/X5GbXKlVdx8umnb/uDmrfXiDQej/yv58M8p1fkOHuWcMxYD03Gx1frblMSx9DL9JlW1DnEq247bSNWSSuJ6CpT4xY1xsgT6/YBLzn30KrsplYB0f8GgEHU0dn+UqEOlDxa+RoifpEjFXQ==
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=selector1-omnitorab-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=32seFceQ/MrQHIgbdnk5C/k5saF+Ju8VaY+/6iBw+68=; b=QvMOmGUPACq0gCIS5vr9AWP/UZXN8p2AZ746J62aaDcvQo8RBrF1sF7YyFhiLA5Cc0SEBENVD0ypomg9DnKzqNJUtVrDQ8C8wmeAmWhOO4RbxJKf8y9WkMikf8p8CMm8Ya+I1EAiYIvXJlsCJftm1yLEf1qDCKT3M+HflYKVOH0=
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM (10.186.178.76) by VI1P193MB0192.EURP193.PROD.OUTLOOK.COM (10.175.182.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.26; Wed, 25 Sep 2019 21:39:12 +0000
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::1835:6533:1158:2507]) by VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::1835:6533:1158:2507%3]) with mapi id 15.20.2284.023; Wed, 25 Sep 2019 21:39:12 +0000
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
To: Bernard Aboba <bernard.aboba@gmail.com>
CC: Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>, mmusic WG <mmusic@ietf.org>
Thread-Topic: [MMUSIC] T.140 in Data Channel scenarios - SDP support
Thread-Index: AQHVc941FhVr12DOkEigKs4uOWK5/ac84rUAgAAI34A=
Date: Wed, 25 Sep 2019 21:39:12 +0000
Message-ID: <a026e3bd-6621-181c-34f3-ff5d296535a1@omnitor.se>
References: <CAOW+2duiD8ZTDQpzupfC9S7tp7k6Xm5K2vA+643RMTpkDCnsMQ@mail.gmail.com> <HE1PR07MB3161640EC7A7269FE3A0D11993840@HE1PR07MB3161.eurprd07.prod.outlook.com> <VI1P193MB06698BA67FA8D8C5050BF10CFB840@VI1P193MB0669.EURP193.PROD.OUTLOOK.COM> <CAOW+2dv1YQ-UtXBWj5RZ=FDGvGKmjV+mwjQH4TAyFsbe75ivEQ@mail.gmail.com> <VI1P193MB0669B64299BDD4D0A39573ACFB870@VI1P193MB0669.EURP193.PROD.OUTLOOK.COM> <a5b5c943-3079-d2dd-988c-e2b3c853c37c@omnitor.se> <CAOW+2dvVGVzpN_VpJAnz_gtGwnxzh6xEUj4f0Z45ityjqkTOEQ@mail.gmail.com>
In-Reply-To: <CAOW+2dvVGVzpN_VpJAnz_gtGwnxzh6xEUj4f0Z45ityjqkTOEQ@mail.gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P123CA0047.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600::35) 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: [77.53.231.170]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: be10d469-ea47-4a4d-b7da-08d74200cde5
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600167)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:VI1P193MB0192;
x-ms-traffictypediagnostic: VI1P193MB0192:
x-ms-exchange-purlcount: 12
x-microsoft-antispam-prvs: <VI1P193MB0192DCA99E2322BD02FE1969FB870@VI1P193MB0192.EURP193.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01713B2841
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(366004)(39840400004)(136003)(189003)(199004)(2616005)(476003)(7736002)(102836004)(8936002)(54906003)(6246003)(4326008)(486006)(86362001)(966005)(186003)(26005)(6506007)(386003)(3846002)(6116002)(606006)(8676002)(85182001)(81166006)(81156014)(53546011)(5660300002)(71200400001)(71190400001)(31686004)(25786009)(446003)(11346002)(30864003)(66574012)(66066001)(256004)(14444005)(99286004)(2906002)(5070765005)(36756003)(6916009)(76176011)(85202003)(52116002)(236005)(66476007)(66556008)(54896002)(6512007)(66946007)(229853002)(64756008)(14454004)(66446008)(508600001)(31696002)(6436002)(6486002)(316002)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P193MB0192; 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-message-info: LCv/IhIlFGfFRe8IZ0m9Gt6fzMrQ84FEPN7wOtSxMMAq5ON+K07WVXJfsdz3fhAdBENFAH2JrcejR5PHXnWJmbEc9z3WjabOtt5EClTYp8zgrqZFhtH2q8A/8Pf51R+Fb2J+9vqjlUWQ282+kwhFcldxpunOUtlUbpLfKstqAooFvLnSzI5cO5zKY9j4PHJax0yCZUVIqsEb3x0C1HG+fMIlfyzcXexCNk/UgOwmHTfmDSgLgYq+U329IorcTD/QRvGIIz7pL78qCXunaQ5T4nls8IOCTXhiafbBRld6z8umsLL3/wsUlEo3q0BaTaa0w6okIZtWiCZDWJ1kVN2CGLVtfz0R7MHQKeGvyw2AdXHgPmgzIB9DpqB9yZ2csTUWNJjA+LGfnU/KZSYb+8PlCqaqxH7n4lKb71wFggTF4dWTdjdIcafdgxTHWlU4b2y2pQehMidq4gEjx5PnUbyvdA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_a026e3bd6621181c34f3ff5d296535a1omnitorse_"
MIME-Version: 1.0
X-OriginatorOrg: omnitor.se
X-MS-Exchange-CrossTenant-Network-Message-Id: be10d469-ea47-4a4d-b7da-08d74200cde5
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2019 21:39:12.0303 (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: lPGNnopYxFJA3qUj7OkCpJbR4BcPhaPFd6VHSE8Edur3mN25IHhDynQCE9Xha/Uwv0KLdtrBVU/pKUWa31faltQ3gst3xKjAIq7vPO5MbrU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P193MB0192
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/CylPE7nvanxaOOdBjDp_B7U7VhM>
Subject: Re: [MMUSIC] T.140 in Data Channel scenarios - SDP support
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 21:39:21 -0000

Den 2019-09-25 kl. 23:07, skrev Bernard Aboba:
The latest WebRTC API specification is here:
https://w3c.github.io/webrtc-pc/

While WebRTC applications are free to use whatever signaling they like, the SDP utilized in the WebRTC API is described in the JSEP document:
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep

While some statements in that draft seem to indicate that customised SDP for data channels can be made through that API,

section 5.2 limits the scope to RTP media.

"


5.2<https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26#section-5.2>.  Constructing an Offer


   When createOffer is called, a new SDP description must be created
   that includes the functionality specified in
   [I-D.ietf-rtcweb-rtp-usage<https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26#ref-I-D.ietf-rtcweb-rtp-usage>].  The exact details of this process are
   explained below."

Can you please check if the intention is to be able to negotiate data channels and their individual dcsa attributes?



Attributes such as hlang would not make sense for use in the WebRTC API because browser themselves do not have language preferences (though it might make sense for a WebRTC application to use hlang in its own signaling).

hlang makes sense. The main targets for hlang are the users who need to know in which language they will be able to start the spoken or typed or signed session. The browser just need to convey the values between the user and the attributes.


The question is for all dcsa attributes: cps , format, directions, hlang

Regards

Gunnar





On Wed, Sep 25, 2019 at 1:17 PM Gunnar Hellström <gunnar.hellstrom@omnitor.se<mailto:gunnar.hellstrom@omnitor.se>> wrote:

Hi,

We have a note in section 4.2. saying:

"NOTE: At the time of writing this specification, the latest verion of
   the API defined in [W3C.webrtc<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#ref-W3C.webrtc>] does not support the use of the SDP
   attributes defined in this section."

However, now I found that sections 4.4.1.6, 4.6 and 4.7 of the W3C API for WebRTC contains specification
 of SDP negotiation and customized SDP contents.

I would like to get comments if that SDP interface is flexible enough for including our dcsa attributes
and performing an SDP negotiation of a T.140 data channel.

If so, we should delete or reword that note in 4.2.

This is the W3C spec I read: https://www.w3.org/TR/webrtc/


Regards
Gunnar






Den 2019-09-25 kl. 21:26, skrev Gunnar Hellström:
Hi,

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".

[GH] Yes, I expected that. Even if the data channel protocol has ambitions to report what data was sent and received before a failure, I am sure that there are error situations when this ambition cannot be satisfied, and the applications is left not exactly knowing what was transmitted successfully before a channel or association breakage.

This finding calls for reviewing wording in two places in the draft,


------------------in 5.4---------------------
5.4<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-5.4>.  Loss of T140blocks


   In case of network failure or congestion, T.140 data channels might
   fail and get torn down.  If this happens but the session sustains, it
   is RECOMMENDED that a low number of retries are made to reestablish
   the T.140 data channels.  If reestablishment of the T.140 data
   channel is successful, an implementation MUST evaluate if any
   T140blocks were lost.  Retransmission of already successfully
   transmitted T140blocks MUST be avoided, and missing text markers
   [T140ad1<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#ref-T140ad1>] SHOULD be inserted in the received data stream where loss
   is detected or suspected.



----------and in a bullet point in 6.. Gateway considerations--------

o  If the gateway detects that the T.140 data channel has failed and
      got torn down, once the data channel has been reestablished the
      gateway SHOULD insert the T.140 missing text marker [T140ad1<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#ref-T140ad1>] in
      the data sent on the outgoing RTP stream if it detects or suspects
      that data on the T.140 data channel was lost.

-------------------------------------------------------------------

Situations when the channel is torn down because of error are expected to be very rare exceptional cases. How the text session behaves in such situation should not be required to meet the requirements in T.140.  Looking at how current multimedia conversational applications handle similar situations, it seems common that for human operated apps, the user gets alerted by a message box with text in this style .. "Problems are detected with your Internet connection. We make efforts to get back to normal operation." And eventually, communication is recovered and you do not know what was lost.

Such actions could be recommendable also for sessions containing T.140 data channels, but it is a general app behavior towards users that may be less relevant for us to specify.

Looking at this phrase in 5.4: "

Retransmission of already successfully
   transmitted T140blocks MUST be avoided, and missing text markers
   [T140ad1<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#ref-T140ad1>] SHOULD be inserted in the received data stream where loss
   is detected or suspected.

"
There may be T140blocks in the data channel transmission buffer that have been transmitted, and received by the other party, but not yet noted as successfully transmitted.
So, in order to obey the MUST for not resending already successfully transmitted text, nothing that is in the transmission buffer may be resent after reconnection. So, the normal action should be to ignore any text in the transmission buffer, insert a missing text marker in the transmitted text if any unacknowledged text was in the transmission buffer at the time of the failure.
It is harder for the receiving side to analyze if anything was lost in reception over the break and reconnect. But it could be a general advice to insert a missing text marker because some text may have been lost.

So, the analysis calls for just a small modification to add "sent and" in the last sentence to make it read:
"

Retransmission of already successfully
   transmitted T140blocks MUST be avoided, and missing text markers
   [T140ad1<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#ref-T140ad1>] SHOULD be inserted in the sent and received data streams where loss
   is detected or suspected.

"

For the wording in section 6, gateway considerations, I find that the existing text is good, but marking may be needed also in the transmission direction towards the T.140 data channel. So, I suggest to add that in the bullet point to make it read:
----------------------------------------------------------------------------

o  If the gateway detects that the T.140 data channel has failed and
      got torn down, once the data channel has been reestablished the
      gateway SHOULD insert the T.140 missing text marker [T140ad1<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#ref-T140ad1>] in
      the data sent on the outgoing RTP stream and on the outgoing
      T.140 data channel if it detects or suspects
      that data on the T.140 data channel was lost in the corresponding

      transmission directions.

-------------------------------------------------------------------



Regards

Gunnar





On Tue, Sep 24, 2019 at 3:08 PM Gunnar Hellström <gunnar.hellstrom@omnitor.se<mailto: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<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







_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic