Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel-gateway considerations

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 29 August 2019 08:37 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 5F370120103 for <mmusic@ietfa.amsl.com>; Thu, 29 Aug 2019 01:37:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 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] 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 3xo2h4-pZp4H for <mmusic@ietfa.amsl.com>; Thu, 29 Aug 2019 01:37:12 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40043.outbound.protection.outlook.com [40.107.4.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB17A120020 for <mmusic@ietf.org>; Thu, 29 Aug 2019 01:37:11 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oBlBcUwBAvy5qT3sfuQXuuqZqw7kQ3o1ZhxRk7IZ+ZUfA+WGtlNNVF+Ek3byaeXjHvdVJ9K+n29lohOqxMUp/TBK0KiIxB1ui0Ke49o+Gv+HWMGEzw964vhJl7jy1Iq/Fyo27LBf0O1zoYo9FWRCbcuUiH1lpe7/zsu0KR1stu8+vobNBNl89Q8r2+umDAybf/l1Li+u4FF6I/Re8NWRhbmoKK9O5DsVxkyVvNJPNGZxcTSWmGd8oBe+6E69+3VE9saIg+068yBI90c7fOB3DPzEh0qWSHKI5avMK3nuCpcMyfKmeZXyM+1seDYm6W2Sntwiygam6t/owTyKeOGEqA==
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=XtyWMgzZ8ZeoHqC6vWKVeppSfUdg6Yrq9Zx7II9GJkg=; b=eo80LmsZQKo7wqgqzhJXv5gpwq+3l15sqZ2pK1jyKiCLUib+V8FTp/RFnsq1QR+ZKdIgFKTC9av6Qfv9Sa885klnyzSdIJMi9oQhUVVtTvpkN5yh9ITmkDQutxOqnjTyLpd97dMj3SU/znDLwez/yPlSdfZo/yvQP0XDYORx+L2d96+o1GRKidKNVWU6KrMv9Gba86ApgyINMN1VqYSZQxwddEBru2bZkcVOl6GIFAXfea+HiM/dn/Q+07GzpJlyHuno1aFAPg7y/Z5t/g22iFPOKhV1hFpQqokdyx3eTX/gqXmngTzu4/qtVxVoZ3kaEc5iYQVQRl30xBDzQt6isg==
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=XtyWMgzZ8ZeoHqC6vWKVeppSfUdg6Yrq9Zx7II9GJkg=; b=m5RV5v5/C+miIJLMyCNX0kLDviI4zq/khMJprs9VRRBDBR8bYNF5f8mXGFV8bnL7PA85y07XHYVwstuYH9rjw/NPzpFZgGT8jAuFQ79sHj0Q5VhIXd2eft6BzTstJWGSN4X/i37kcdJAcyRy7x4Xd1UQ6rCJPIeki1x9PrIobCA=
Received: from AM4PR07MB3156.eurprd07.prod.outlook.com (10.171.187.141) by AM4PR07MB3396.eurprd07.prod.outlook.com (10.171.189.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.4; Thu, 29 Aug 2019 08:37:09 +0000
Received: from AM4PR07MB3156.eurprd07.prod.outlook.com ([fe80::80eb:171e:dd12:a00c]) by AM4PR07MB3156.eurprd07.prod.outlook.com ([fe80::80eb:171e:dd12:a00c%7]) with mapi id 15.20.2220.013; Thu, 29 Aug 2019 08:37:09 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= <gunnar.hellstrom@omnitor.se>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: draft-holmberg-mmusic-t140-usage-data-channel-gateway considerations
Thread-Index: AQHVXkGe2BMFZo2IX0CeoSmDzlROjacR/6oA
Date: Thu, 29 Aug 2019 08:37:09 +0000
Message-ID: <4A020B23-0BFE-4658-8A1C-2F05F960CED2@ericsson.com>
References: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@ericsson.com> <3a2b4d58-7643-af3f-dda3-ea18fe65a0df@omnitor.se>
In-Reply-To: <3a2b4d58-7643-af3f-dda3-ea18fe65a0df@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: b6962f63-0b7a-421d-29bc-08d72c5c14fe
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:AM4PR07MB3396;
x-ms-traffictypediagnostic: AM4PR07MB3396:
x-microsoft-antispam-prvs: <AM4PR07MB3396207B30E7B8210ABA72B493A20@AM4PR07MB3396.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0144B30E41
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(39860400002)(376002)(366004)(396003)(51444003)(199004)(189003)(66476007)(186003)(64756008)(66556008)(66946007)(76116006)(91956017)(99286004)(102836004)(25786009)(6506007)(7736002)(76176011)(86362001)(26005)(305945005)(66446008)(316002)(2616005)(476003)(11346002)(58126008)(110136005)(2906002)(81156014)(14454004)(8676002)(6116002)(6486002)(81166006)(486006)(2501003)(36756003)(8936002)(446003)(229853002)(3846002)(5660300002)(478600001)(53936002)(66066001)(44832011)(33656002)(14444005)(256004)(6246003)(6512007)(71200400001)(71190400001)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3396; H:AM4PR07MB3156.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: krz44qRulV9jzBRAlhFb0FLHIA0UZ0vLEq4CAHaxkwHRkR1sjhBC3YedI8JKhOsVXErDFm8cG8kTJre0TvK+w7fGKR6HCzJYXDjhdlOdgnp1PbceUyQUhq3Cwe3zlBLeYGkbRItML7twcpr8npk0SWEr2Oly+KEiZPJFDjDr39f8CqM36whSHWz4zlk4Hw6yvVcg7uxgG94ab0GLVNKxM4a81YXfzo6iBOVQEPyMWRDAEB0rUCqenfIdhcnxg4moJEjakG69qwaO5OZ7qxdN0IKb73Bw0yaE1abzn+Zw7sQIAd9EvusxMjqzLEZZCu5YcoIFPrmelMvfAOnIl9ZSFz605ZPLGGJjFDRe9LyHICSREIXhGkSy/4Rm+kH6hXwcsqd/tdV6YL7gluK6h9iFx2QP7nUG9NJGpvms/DAC4KA=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <0DC946B1774F9D4B8B9B4DCA01A99600@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b6962f63-0b7a-421d-29bc-08d72c5c14fe
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 08:37:09.5739 (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: qXYCy5Fzfl7AlW3mALO0T/UdUOEcyvhq2sz0Gx0qDC5sJodlfYetmtZQjRjjqrVLgZc0EhN/7Vg/qz4DGvXRBdG5iyJDKo8nr/Gb/4VV65g=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3396
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/F_OcKPN0uZWLABV3S8imjFGxYvs>
Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel-gateway considerations
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: Thu, 29 Aug 2019 08:37:14 -0000

Hi Gunnar,
    
>    1. Keep-alive.
>    
>    In the gateway considerations section, there were a few sentences about 
>    keep-alive. It was stated that RFC 4103 does not specify any need for 
>    keep-alive. That is true, but because RFC 4103 specifies that 
>    transmission occurs only when there is text to transmit, there will be a 
>    need for keep-alive traffic in many network configurations. On the data 
>    channel side, this is implied in the WebRTC data channel, but on the RTP 
>    side, the need for keep-alive must be considered. This is mentioned in 
>    RFC 6263, where RTCP multiplexing is recommended as the preferred 
>    option. Most current RFC 4103 implementations however send keep-alive by 
>    sending the Unicode BOM character at suitable intervals, and these 
>    should be extracted and deleted by a gateway on the way from RTP to the 
>    data channel.
>    
>    Even if we have said that we cannot have all gateway considerations 
>    documented here, I suggest that a couple of words about RFC6263 
>    mentioning the possible need for keep-alive on the RTP side are inserted.
  
The text in -01 says that the gateway may have to extract keep-alives from, and MAY add keep-alives to, the RTP stream.

We can for sure reference mechanisms normally used to implement 4103 keep-alives. 

But, if you want to define *generic* recommendations/guidance regarding keep-alives on 4103 streams I think that shall be done in an update to 4103. There is nothing data channel gateway specific about that.

---
  
>    2. Sendonly, recvonly, etc
>    
>    On the RTP side, there is a possibility to express directions in SDP by 
>    the sendonly etc. attributes. I think I have seen them used in RFC 4103 
>    implementations.
>    
>    Will these attributes automatically be possible to use in the T.140 data 
>    channel? I guess not, because it is not really said that the T.140 data 
>    channel tries to be a replica of the RFC 4103 RTP transport with all its 
>    possible attributes. Some of the attributes enabled for RFC 4103 may be 
>    of application interest for the T.140 data channel application, while 
>    others are of little or no interest or irrelevant. I am afraid that we 
>    need to go through possible attributes and mention the relevant ones in 
>    a general section on attributes, and then IANA-register the use. (this 
>    relates also to the current discussion in another thread about IANA 
>    registration of attributes for data channels).  The msrp-data-channel 
>    draft has a section on sendonly etc. I suggest that we also include one.
  
The data channel itself is always bi-directional. Now, if you want to allow usage of direction attributes for T.140 data I guess we would have to define usage of them inside a 'dcsa' attribute.

Regards,

Christer