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

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 23 August 2019 10:09 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 2BDC2120088 for <mmusic@ietfa.amsl.com>; Fri, 23 Aug 2019 03:09:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nerJ1oUv2otW for <mmusic@ietfa.amsl.com>; Fri, 23 Aug 2019 03:09:32 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on0610.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::610]) (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 5865112006D for <mmusic@ietf.org>; Fri, 23 Aug 2019 03:09:32 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BxwrXoQQ+HNhu0iuHevB2uu4qzpc2GYxGuFF7XxL35bQRARt6CdUP5ZEqrDzbPaEmUZG1F9mMsI7uyIa7ySkPDXCYjDAmaVngYSdVK7ZdxWHzFu36rnbhbf9LuLYqBL6hNHofpziLeRPaPuyPdN8/5cGKZsfoM80z+PWBhA59vZXGlFUOazO6IxaORHKvut6Km9XI385d5wzbOHZbO9gnjQKluYXC/JaVer/Gmeu2xS6SG7s2lb2wxPnoUPOWQWMSeilHNLg4ed0DxfBKhB76mh8DFrxPXNITemYsAZahNDEb1mowu0LFk9N9egmYhDYqfIj6fUvtWkdqwSOtBtSuA==
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=itbdlnoheqyRqQ4pShNpGDGiqkoNCmkXX6wS02sLBRo=; b=gJsAG5BwnSXPpMNlLuPLH7b7IE2KBqwGZgh4wXrmHBz4fy5iqB4wGTgJtBWRw+TvOiCdIIB2yubJKCL/6oe+13cYuQydFr/rkIKULtNbS7IsEjQrEPAJl5xTcax/SWDiUuVJbYDuUbzDiGOUoxTIef1WrUs2i1cIMUu3L0MKec2Idt+IYUsa+UMc55dvUydEdnPvK5RCsgN9E99seQxEEpsjpmlR/mG2tSMRINhVnHPzxD0gAEMdnAqefZrXgcdeBHVRX8AvbgxM6DeNpM9GcYqoorL2j6P8dxxfUa20TeQbWq++TPsFto1tqX7nHbqYGe1feiskZTk3A1nDMv0Veg==
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=itbdlnoheqyRqQ4pShNpGDGiqkoNCmkXX6wS02sLBRo=; b=kSt1aD4mzd/Rf2jIjrRVVNpyRyXOi/jAA3VkbBcQ0o+rOLIvOyvH24b/HEcmbaJvdKLaJ94njxk3Uk0EsNL9sKpmh8htpGGwL+Co1rDGwPq+ilXkhCl3tibR+xEHCim12zkSWDZ1V12HFLW7AHMrGol8lKDfx+uW+icTG2HJq4U=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4220.eurprd07.prod.outlook.com (20.176.166.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.10; Fri, 23 Aug 2019 10:09:29 +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; Fri, 23 Aug 2019 10:09:29 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= <gunnar.hellstrom@omnitor.se>, Bernard Aboba <bernard.aboba@gmail.com>
CC: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Draft new: draft-holmberg-mmusic-t140-usage-data-channel
Thread-Index: AQHVTtmu0b05snoDfkq4tQT6JA1d/ab+b6CAgAB3E5CABz7XAIABGpmAgABASoCAADPOAIAABFXggADdQoCAADR4gA==
Date: Fri, 23 Aug 2019 10:09:29 +0000
Message-ID: <0DA1248C-41FC-4155-A578-29A19883857C@ericsson.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>
In-Reply-To: <8d14b055-8405-4a4f-174d-d7580bea348c@omnitor.se>
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: fe69ee80-759d-4176-ccfe-08d727b1fcb6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4220;
x-ms-traffictypediagnostic: HE1PR07MB4220:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <HE1PR07MB4220899D5CAD8D6E581208A193A40@HE1PR07MB4220.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 0138CD935C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(136003)(396003)(39860400002)(199004)(189003)(256004)(81156014)(305945005)(4326008)(14444005)(25786009)(33656002)(6246003)(7736002)(966005)(53936002)(478600001)(14454004)(6486002)(229853002)(76116006)(6306002)(66556008)(486006)(66476007)(64756008)(66446008)(66946007)(44832011)(6512007)(6436002)(86362001)(5660300002)(476003)(2616005)(11346002)(76176011)(36756003)(446003)(66066001)(3846002)(6116002)(26005)(186003)(58126008)(8936002)(102836004)(66574012)(71200400001)(71190400001)(316002)(6506007)(99286004)(110136005)(81166006)(8676002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4220; 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: 1C2kmpYIF2ZsmdjvH2F4jnR5enNKu2gHwMFERlC+xBOYhL0UGmQoAJyWiPAQir2FKyJ0x3vGzzhaZsau+h2BxZNRNc+DEx0pB9mcCHGjr2n2mx31y/P3c5PI26Usz3KH/23GmZhnY2dr2+iAekOjSTrgHIrQT1FZP2Tza6ooWJaisWcdLKbEvFfX/UqkQ3CPT8BGkoz+Bd/wUu1gf/Ne3l566JIuPoQR/Y5lwSAY2PgaK2fHc7Tawd6J9KFJGzxNGwJmYi1igNWQvk5dJS720vv8Q51jl3wLRyOMZcY69Hw3aTui2cjlWn0M4OeQZ6uVWtVPdpIJ9EIwIVOgSxOIl1eGuvs1Q1oIREFTpJE8E+TSevMIK9dbB2jq1euuYu4LfQpFj2HnId1GpCT/Ltq8fpv6UlCJS6tIdhKzglN1hpA=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <C5E83AB3ED1EA74FBB32D93C36D15766@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fe69ee80-759d-4176-ccfe-08d727b1fcb6
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2019 10:09:29.7608 (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: 5CBh/11PfmaIEe5/RrizXqHNY8SivSTiX5pbxX5kBKFsJ4FtGeWVa/M7xlW4rzCoTpqEMitPkQz6HSiQjB+HKPg+zQl8rOgW6I7C6AFPPxQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4220
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/PhlZ-oUmGpmjzOMDmaRe5o_prRo>
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t140-usage-data-channel
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: Fri, 23 Aug 2019 10:09:36 -0000

Hi,

>>> I want to add one issue for the security section: Can we specify a way to achieve end-to-end encryption of T.140 
>>> data between a WebRTC endpoint and a traditional SIP/RFC 4103 endpoint through a gateway? I know that that is a 
>>> desired feature.
>>
>> How would you do that? The data channel uses DTLS encryption, and SIP/RFC 4103 uses SRTP encryption, so 
>> doesn't the gateway have to decrypt/encrypt the T.140 traffic?
>    
>    I have just heard the requirement to have end-to-end encryption of RTT, 
>    I do not have the solution. One possibility would maybe be to have media 
>    encryption end-to-end as well as the two transport encryptions. But that 
>    complicates the possibility to insert the missing text markers by the 
>    gateway if text loss is detected.
  
Yes.

However, keep in mind that the scope of the draft is how to use SDP O/A to negotiate a T.140 WebRTC data channel. We DO include some text regarding interworking with SIP/RFC 4103, because we know there are environments where such interworking takes place.

But, extending T.140 and/or RFC 4103 (e.g., defining a new application level encryption mechanism for T.140) is outside the scope.

Regards,

Christer



    >
    >
    > Den 2019-08-22 kl. 16:28, skrev Christer Holmberg:
    >> I have created a pull request, which will be used for the changes based on Gunnar's comments:
    >>
    >> https://protect2.fireeye.com/url?k=f453465c-a88743e3-f45306c7-868f633d
    >> bf25-4deb49c05b8a2375&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-d
    >> atachannel-t140%2Fpull%2F5
    >>
    >> Regards,
    >>
    >> Christer
    >>
    >> On 22/08/2019, 13.39, "mmusic on behalf of Christer Holmberg" <mmusic-bounces@ietf.org on behalf of christer.holmberg@ericsson.com>; wrote:
    >>
    >>       Hi Gunnar,
    >>       
    >>       Thanks you for your support (I assume :) and comments on the draft!
    >>       
    >>       See inline.
    >>         
    >>       >A couple of comments:
    >>       >1) In 3.2, the attribute "cps" is misspelled "cpc" once.
    >>       
    >>       Will fix.
    >>       
    >>       ---
    >>       
    >>       >2) Section 5 has some historical references to real-time text transports that may not be of much interest anymore
    >>       >and instead confuse the reader, while some other more relevant transports may be added.
    >>       
    >>       I took these from the schwarz draft. You probably know better
    >> than me which ones are relevant, so feel to suggest which one(s)
    >> should be removed, and which one(s) should be be added :)
    >>       
    >>       >I would also like to discuss if it could be possible to have a few general recommendations on the webrtc to sip/rfc4103 case without
    >>       >the problems you see with having a detailed gateway section.
    >>       
    >>       The second last paragraph covers some things on the media plane (out of order and loss of RTP packets) that I think are worth mentioning.
    >>       
    >>       As far as SDP interworking is concerned, this draft defines the m- line for T.140 data channel, and RFC 4103 defines the m- line for T.140 RTP, and the interworking should be very straight forwards. Do you have something specific in mind regarding general recommendations?
    >>       
    >>       ---
    >>       
    >>       > 3) Reliability. Section 3.1 implies that the channel is used in the reliable and ordered mode. We have been discussing back and forth
    >>       > if that is the right choice for real-time text. I tend to think it is, but it might be useful to discuss it once again. The traditional user
    >>       > requirement on real-time text is that produced characters shall be presented to the receiver within one second from their creation.
    >>       > Modern usage in speech-to-text applications may require more rapid transmission. As I understand it, the reliable mode of the
    >>       > data channel may imply long periods of choked transmission in case of network problems or by influence of heavy transmission
    >>       > in another channel. As long as this happens only in case of network problems, I now tend to think that that might be acceptable.
    >>       > The effects of being forced to use an unreliable channel are so far-going so I would like to avoid that.
    >>       > However, the word "reliable" is misleading. A "reliable" channel is not really reliable. It can break in case of problems.
    >>       
    >>       True, but "reliable" is the terminology used in both RFC 4960 (SCTP) and draft-ietf-rtcweb-data-channel.
    >>       
    >>       > I think some recommendations should be inserted in section 4 about what to do when a channel breaks. The natural action
    >>       > would be for both sides to try to figure out what was the last T.140 data that was transmitted and received, and then try to
    >>       > reconnect and resume transmission if successful. If any T.140 data was lost during the break, that state should be marked
    >>       > by inserting the "missing data" T.140 indicator in the received stream. There needs of course also be a recommended action
    >>       > if it turns out to be impossible to reconnect after a low number of retries.
    >>       
    >>       I can for sure add some text about that. Are there generic T.140 recommendations for failure that we can reference, or do you think there is something T.140 data channel specific?
    >>       
    >>       Regards,
    >>       
    >>       Christer
    >>       
    >>       
    >>       _______________________________________________
    >>       mmusic mailing list
    >>       mmusic@ietf.org
    >>       https://www.ietf.org/mailman/listinfo/mmusic
    >>       
    >>
    > --
    > -----------------------------------------
    > Gunnar Hellström
    > Omnitor
    > gunnar.hellstrom@omnitor.se
    > +46 708 204 288
    >
    > _______________________________________________
    > mmusic mailing list
    > mmusic@ietf.org
    > https://www.ietf.org/mailman/listinfo/mmusic
    
    -- 
    -----------------------------------------
    Gunnar Hellström
    Omnitor
    gunnar.hellstrom@omnitor.se
    +46 708 204 288