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

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 23 August 2019 13:08 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 851D412083F for <mmusic@ietfa.amsl.com>; Fri, 23 Aug 2019 06:08:41 -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 9EW_lpZuyGgo for <mmusic@ietfa.amsl.com>; Fri, 23 Aug 2019 06:08:39 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20064.outbound.protection.outlook.com [40.107.2.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A03A12083E for <mmusic@ietf.org>; Fri, 23 Aug 2019 06:08:38 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WLHMh5VD+5DTaA0vs1ZAdKc0I7z/QQn5iNcuvuiBe1y0UIo6U/bio0GSWAo3JJGEHajIC3Aa2HqwZOzL3aSGGVeHIkuKf4Z6Kqrq+0BMIqyicgZy79HdsSvvRqDEdPF/eMt72ysMO0FfRDPx8i3WjSfK+xM8/b+h/O/RLt546RkTFtImDm62gOCTqeTpvIBhwdDZxoxsr4WOCBk9NQi9pSiIkmSHwL4e3dqQsIVZEw4kMM4XXYKBx1Q6wXj7/Uhmy0rI5iPMygEjV+C/OM6v7h6fCptNQWbL+JdMwytsCA6+SoQRJX+DfD6J8gCZ4DQTByXXxa28XplLbVWo/Irz1A==
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=6YsHX6SNsgBciVFXLWH6Hs6oW85dOP4ZhbkN6TaA60M=; b=edkYMf0hsEUNREstMTYa0uREEBiG8vozrLMwtad6FeK2Fvba1624Mkp6Gt+hRffQL7flFCtkCEUe/REmYTcvzf5cJjvE4l43iZ3BSW1hO5x1SIJmayeJrmd2r1ztN7EFpD8qwPwX0qR+v9YChow8xBoghtTneA89FhTqy67EWq+pG+HdOERc0MDxc3yfUOtkSDpiS2b/Rnnzv94r53UZ6EAJtZJJrT7fRdulchPbiMBjySJ5bsnyOlwUiXXTkWaIZ6nVNmBwqhEBoucFkoIHPR6HrTUNqqZIy7zUY/h4UZOlEq0mjMtjudfmQd737itBh+Rs9GL3/2nm+11z3bbHCw==
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=6YsHX6SNsgBciVFXLWH6Hs6oW85dOP4ZhbkN6TaA60M=; b=QMIqVLDYf5W/4EsYWMnot6NfjWuCx7WiiC03wPKkbXQ7IE2rziy6hPZXY23V+/P7vzhMSGMRiSwqpXfckRizyJ6MucA4eex8IGDxmVIDthV/AT8tmisAmSmLiP14Kfoi2yNjlosLiFX2HHc5fQvWKyQfnL+cMSbjJsiADMcmc1Y=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3211.eurprd07.prod.outlook.com (10.170.246.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.15; Fri, 23 Aug 2019 13:08:36 +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 13:08:36 +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+b6CAgAB3E5CABz7XAIABGpmAgABASoCAADPOAIAABFXggADdQoCAADR4gP//+tyAgAA3LoA=
Date: Fri, 23 Aug 2019 13:08:35 +0000
Message-ID: <DBC532B8-38DC-4140-B7C4-0B6853F0EF77@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> <0DA1248C-41FC-4155-A578-29A19883857C@ericsson.com> <a91850b9-6e86-058f-dddd-3f856bcd6710@omnitor.se>
In-Reply-To: <a91850b9-6e86-058f-dddd-3f856bcd6710@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: 380665a7-1e66-4505-41a8-08d727cb01f3
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3211;
x-ms-traffictypediagnostic: HE1PR07MB3211:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <HE1PR07MB32117943642EABE97F5367D193A40@HE1PR07MB3211.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5797;
x-forefront-prvs: 0138CD935C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(366004)(39860400002)(376002)(346002)(189003)(199004)(6246003)(58126008)(6306002)(6506007)(53936002)(7736002)(81166006)(316002)(76176011)(14444005)(256004)(33656002)(2906002)(11346002)(66066001)(110136005)(102836004)(26005)(25786009)(64756008)(66446008)(76116006)(66556008)(6512007)(446003)(66476007)(486006)(66946007)(14454004)(66574012)(305945005)(478600001)(966005)(6486002)(8936002)(229853002)(86362001)(44832011)(4326008)(3846002)(6116002)(186003)(36756003)(2616005)(71190400001)(99286004)(5660300002)(71200400001)(476003)(8676002)(6436002)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3211; 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-message-info: QUEhroW9+AAGVioMKDJNoIxjWOtkVI46i+3hZX5RwSb3J890nt90BT/WS1pLkxhp7ueX1Epo9jdvRDlvHRnHZBHfhTOE6IxT3iyUY7q+2FleTqKFTnRkVOwAd9T+hmnI6tc863WAAqQ0d3iiki+STtLKu5wf1tpVD1+l60DR/jaZUGnyHgf44PurLZ9OUMxa0W/iDFRlJUg76BC1sDXfJJsVt0zoX+o0h6s1mYYAeReE+e0bfHIdgDSq1hxWOeI5UH8lOhHtJ9NDGWhaxM16UXBru8U62PZwCeI8J1AChQe3M6ThVMVa0TxTUg/LRQxD3sMvrEtURFGAdey1oHbQkdSjQjdL+OUeQlFH//9eJDXYaivgJ8/6Fv4gXtUUFvPsGz96gVMZvuYT+Vdz4mnT4uI+Ls2652rmvX+7YsBictE=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <DF7FC6976B69994ABB87DF674254CFD5@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 380665a7-1e66-4505-41a8-08d727cb01f3
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2019 13:08:35.9928 (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: wIo8KGRwmX0j+H0UlqLdDCscuSpwDNqZFNOgsLXYJZMopWKjTV4WWX9+psH9YeEzRUE6uttMKu9WhGFS6VtsYeYXbdSFX3Lr1JDuwe4J9Lc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3211
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/-OwKJodZOWhtdbCtgJrL9TzViJc>
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 13:08:41 -0000

Hi,

>I hope I can stop introducing new topics soon, and contribute to resolving them instead... But another topic to cover is multi-party session >support.  The requirement is:
>   U-C 5:  Realtime text chat during an audio and/or video call with an
>                individual or with multiple people in a conference.
>
> I hope that will be straightforward.

I can't think of any impact on the document based on that. The SDP for such conference will contain an m- line for the T.140 data channel, as described in the draft, and m- lines for the RTP audio and video streams (described elsewhere).

If there are some additional conference specific SDP attributes are needed for the T.140 data channel we can add them, but I can't think of any.  

Regards,

Christer



Den 2019-08-23 kl. 12:09, skrev Christer Holmberg:
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" mailto:mmusic-bounces@ietf.orgonbehalfofchrister.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
    >>       mailto:mmusic@ietf.org
    >>       https://www.ietf.org/mailman/listinfo/mmusic
    >>       
    >>
    > --
    > -----------------------------------------
    > Gunnar Hellström
    > Omnitor
    > mailto:gunnar.hellstrom@omnitor.se
    > +46 708 204 288
    >
    > _______________________________________________
    > mmusic mailing list
    > mailto:mmusic@ietf.org
    > https://www.ietf.org/mailman/listinfo/mmusic
    
    -- 
    -----------------------------------------
    Gunnar Hellström
    Omnitor
    mailto:gunnar.hellstrom@omnitor.se
    +46 708 204 288
    
    

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