Re: [MMUSIC] T140: Usage of "-"fmt value in dcsa encapsulated fmtp attribute

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Fri, 13 December 2019 11:05 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 B330C12009E; Fri, 13 Dec 2019 03:05:13 -0800 (PST)
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, HTML_MESSAGE=0.001, 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=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 GLib34NOYn6E; Fri, 13 Dec 2019 03:05:11 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10115.outbound.protection.outlook.com [40.107.1.115]) (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 B424A120047; Fri, 13 Dec 2019 03:05:10 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EcoAGYIymUeQBwNe/oMZHkZdyKFtg0mYQhx1q/vVp9v9xQE63LQ3yPesvJEXPF7G/a9ybMRJLCKuayFCvNStuNKI2SbUA1Ii0LRqWdwCYolGJLlPeKVq/xuga2zPQQWDaoM1uojLadD+3aB4FUOqAR7Bb7I4ZLCr7YWsJvCq2T7J8KYWV4hnj3rhWkbfmpvkccux5h+4SeVJFgYlQBMMsrnNPFH5x+uA4x4FHhimxOhquLDxR4EbtNeXg8KR2coVUJALg72+jt+2b66/EDJfblMOuAA8nWHqSsv0pFf1DEDdvxiygxeAgr2ljgSU460kovCGeVEasBdmXaZF5a4BvA==
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=TtVCFwLH4CHPmAvyvBRt3uYyt4Xuw8tjhKbVUAJgi7Q=; b=G7Cdao9PLU7p1wLK1RrD0DWMq/D8HoSofdv3jKamYfRWgeuotkW8CWZZlqB+qcA9oUxMn3XQdE7p89XsTrPG4ATZqxaLq5UyObgJy9VSyfnWIUinJaC7AmFf40Q2P5hMsEi5fTyoT680vVVdbx6aS7RR4vN4e7BCDhrzbWgqW+/xnFGGJhTifh5RTvQIQm0gm+MdZH6fidldfOIe7h/LDlMXM6TR9lm6Yx+Y30HrIHirx+7E5hMRGfxMCoNPLsBMq/fJLkJvGNYsApuDjEDOfw16hiMvY8c16jyXwK10AJPduciGgQQtBmqE4+4nWf5/ZURqYyRZ7XDFYkyDLVSbHQ==
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=selector2-omnitorab-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TtVCFwLH4CHPmAvyvBRt3uYyt4Xuw8tjhKbVUAJgi7Q=; b=YlnTMlOxkMsbY/XLryTiox0cj/cQbvUgJU2eIL++tukFOit8CUOctRivKdZtBw94oqxeFoAGYrOuqqOV+5wBEZ8YINCR5NBgIOGqDMqG2gsPiy5pZOEx0yHI8JOFFzTRN6CWBqVyM77sO9vUscw9EZxSJ1v4xMOq57ae1a/EQ9c=
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM (10.186.178.76) by VI1P193MB0685.EURP193.PROD.OUTLOOK.COM (10.186.177.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.18; Fri, 13 Dec 2019 11:05:07 +0000
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::75eb:27c8:2159:ebdd]) by VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::75eb:27c8:2159:ebdd%7]) with mapi id 15.20.2516.020; Fri, 13 Dec 2019 11:05:07 +0000
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
To: Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>, "mmusic (mmusic@ietf.org)" <mmusic@ietf.org>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>
Thread-Topic: [MMUSIC] T140: Usage of "-"fmt value in dcsa encapsulated fmtp attribute
Thread-Index: AQHVsR/lwYXoivuBwkKJ+MACi8tNi6e36BcA
Date: Fri, 13 Dec 2019 11:05:07 +0000
Message-ID: <1b757fea-b5ce-c498-8100-cb54a4a431fa@omnitor.se>
References: <DB6PR0701MB24219718E7408022DB6F256493550@DB6PR0701MB2421.eurprd07.prod.outlook.com>
In-Reply-To: <DB6PR0701MB24219718E7408022DB6F256493550@DB6PR0701MB2421.eurprd07.prod.outlook.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: AM0PR10CA0060.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:150::40) 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.230.59]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2851f7d2-ea10-416d-1002-08d77fbc5027
x-ms-traffictypediagnostic: VI1P193MB0685:
x-microsoft-antispam-prvs: <VI1P193MB0685EEB252C31A81AE633C51FB540@VI1P193MB0685.EURP193.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0250B840C1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39830400003)(136003)(396003)(366004)(346002)(199004)(189003)(86362001)(508600001)(5660300002)(52116002)(186003)(64756008)(316002)(66556008)(31696002)(2906002)(66476007)(66446008)(6506007)(19627405001)(2616005)(36756003)(66946007)(8936002)(966005)(6486002)(6512007)(4001150100001)(31686004)(110136005)(26005)(66574012)(81156014)(8676002)(81166006)(71200400001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P193MB0685; H:VI1P193MB0669.EURP193.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: omnitor.se does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: EPSjODstuVPNZAlCe2FnTwQ5e4ggPCJTi2nRLt7FmaAuqxZ5F8rULxwHRdkCcr3QL07rbmryc6uvsQ/A+8JOGGCXsUV/0osiUQnz6q4D7q7mtw5nnxVYWZv78R7btMujCBmJLxmDQMR3RYWvC786tyW/RurbjmBRydDyarEvsEeCEi8epxYv3jbCxHtFTIK+aZ4UOQkVxvJkG+jdbfA+BE0iusehgrxYkVPROEV9QiONLWbYTyjewnK4VRtZV9Wq8Dne+WD2oLBxO/t+MOBTkx0ojVyCqFqMWISW4KkwOXhUM3nfZ2c86rooXBlNiZFmApQWG2ODSds0PHir4sBkusYAHB+oRWFfp2+ngmpMFDPAqqhMnoSn3TUO+IDxXL46zWiC44f5TAXQhdlr819W5d67LKwj15DjZwL0x/hJ4m5OYQ7m22eKIpZo/ntypQYI13XldO41IesqwrrOJDLqEaLyeOhTdmtsHYsuIn9bFr0=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_1b757feab5cec4988100cb54a4a431faomnitorse_"
MIME-Version: 1.0
X-OriginatorOrg: omnitor.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 2851f7d2-ea10-416d-1002-08d77fbc5027
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2019 11:05:07.2914 (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: cyUS3I1V2xYhlYWGyx8vPRjI8I8qItv+ORwmeVtNgqa8LlgQBuyWqKLXw9WsEFSxwTAyCla6rXL4H11Bx8jEDZR7T6Hdm7u25CV08MTZZAE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P193MB0685
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/oShWP6gsS3UsZ6jr7-FncfsNV3c>
Subject: Re: [MMUSIC] T140: Usage of "-"fmt value in dcsa encapsulated fmtp attribute
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, 13 Dec 2019 11:05:14 -0000

Hi,

It seems to me that the solution for the "fmt" value definition might be found in sdpneg


In sdpneg section 5.2.1

https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-28#section-5.2.1

It is said:

 "There may be cases, where the usage of a subprotocol related media
   level attribute depends on the subprotocol's transport protocol.  In
   such cases the subprotocol related usage of the attribute is expected
   to be described for the data channel transport.  A data channel
   specific usage of a subprotocol attribute is expected to be specified
   in the same document that registers the subprotocol's identifier for
   data channel usage as described in Section 9.1<https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-28#section-9.1>. "

In t140-usage, section4.2.1,
https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-10#section-4.2.1
we have this sentence:
   'If the 'fmtp' attribute is included, the 'format' attribute parameter
   MUST be set to "-". '

It seems to me that the t140-usage draft by that fulfills the requirements of sdpneg and we are fine with fmt=-
Maybe we could even say that for the t.140-data-channel, "fmt" MUST be ommitted, in order to get a simpler syntax (?).


However,

This issue may also relate to the definition of "fmt" in rfc4566bis
 https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-37#section-8.2.3
where we have the following sentences that seem to apply:
"For other protocols, formats MAY be registered according to the rules
   of the associated "proto" specification.

   Registrations of new formats MUST specify which transport protocols
   they apply to."

I have not traced if we are bound to that requirement for dcsa definitions, and how it would map from protocol to sub-protocol, so I hope we can obey sdpneg.

Summary: I would suggest to omit "fmt", or keep fmt=- and claim that the use of fmt is defined in t140-usage as required by sdpneg.

Regards
Gunnar




Den 2019-12-12 kl. 20:12, skrev Christer Holmberg:
Hi,

When the chairs reviewed the T.140 data channel usage draft, the following issue was raised:

Currently, when we send an fmtp attribute encapsulated in a dcsa attribute, we use "-" as the fmt value.

     Example: a=dcsa:2 fmtp:- cps=20

However, 4566bis says the following about the fmtp attribute:

"The format must be one of the formats specified for the media."

Now, the format is 'webrtc-datachannel', so one could claim that should be used.

     Example: a=dcsa:2 fmtp:webrtc-datachannel cps=20

 But, that applies to the whole SCTP association, and the dcsa attribute is associated with a specific data channel usage. In addition, the usage and syntax of the fmtp attribute may vary depending on data channel usage.

Another option could be to include the sub-protocol:

     Example: a=dcsa:2 fmtp:t140 cps=20

But, the dcsa attribute already maps the fmtp attribute to the sub-protocol.

So, what to do?

My personal suggestion would be to keep "-", and perhaps add a note somewhere. Not sure we would need to update 4566bis, but if people want to do that we could for sure do it.

Anyone having a different opinion?

Regards,

Christer





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


--

+ + + + + + + + + + + + + +

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