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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Wed, 18 December 2019 10:02 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 2159F120024 for <mmusic@ietfa.amsl.com>; Wed, 18 Dec 2019 02:02:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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] 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 zXhn48yX2DMS for <mmusic@ietfa.amsl.com>; Wed, 18 Dec 2019 02:01:56 -0800 (PST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20139.outbound.protection.outlook.com [40.107.2.139]) (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 04766120071 for <mmusic@ietf.org>; Wed, 18 Dec 2019 02:01:55 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Iq/BWSgKqbwOsnJVxGgXSC+912FYO3P0XEL591PkPQ0rRBKqC9P5dwQgzX/nwKMhRvHg2u+tjnxJH6s3oYhOm3Zo56G76rMRvW7pILtMV6wKE8WBXcVtLt6dYdbosef8/UXRfcQSr4uByFgNpYZXHgwSctCAKPSlt9jxCIpEMc9h68ytZTeCbXLHf0LvY+a3nV8ZTbmP7Hb+sIfn0HvvJ5lKLCKcbvLfcGf4rkxgnMmhgsCXMaa8dK3yL5uxHCsAZjVITSbf25SKVxQeycRIV103CLNO6UD6SUFpMvBgm8bun480MOofb9OQyYoHUod/hNKy/4orknvnYuX2MMNpVg==
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=L0ozJENcb7UrPAafdRSHkPWDeamrOPjT5H/80L8ecZ4=; b=ekdiIdfSM667IzDKpww5N6sWscVwvH506RHPRmtcws36bm3oY8b+cothZX8ze6Bxuhwl6GIyktGwtdyUzow/EqnFPaRlAL5bwSOCgV9eQlY0CtudWGJpk2F7veTY4g7mgtU25fgGJijcSR8kBL/zUTPOC00/o1aCRB1dvJFE+i4CEal5Z9pG/uXOCj8PBJ7qlVgYua4jLloXWOAXMKDSJCL8sAkWOkpHCh9Mm/Py5Zna/+Siy1M/MyBbqeU10uh9KNKVBnaMo9XeBl0ZXEiOdFSuVAH0uTc+cfJ8it6NEZobIYWwdBPQuvgN/1InSm0of3mh5zjOmBAgIOAPM/HEEw==
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=L0ozJENcb7UrPAafdRSHkPWDeamrOPjT5H/80L8ecZ4=; b=J013HA+flT+lDGLNqZkL2XhkOqUqWRuXGKMtHd9Kvt+WJdZRt/lhRPpQXiI9pUTpdPPS6ji7NjLX0fhmL3qwefuo+dcDmfx3lWsBlZb2pPcxevrdMInOhLBkmqYXz2V9+zH5DNOQNNIPskQjkiXUHaFg8qI2YsHgzBUgRctH/xQ=
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM (10.186.178.76) by VI1P193MB0527.EURP193.PROD.OUTLOOK.COM (10.186.178.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.16; Wed, 18 Dec 2019 10:01:52 +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.2538.019; Wed, 18 Dec 2019 10:01:52 +0000
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
To: Flemming Andreasen <fandreas@cisco.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] T140: Usage of "-"fmt value in dcsa encapsulated fmtp attribute
Thread-Index: AQHVsR/lwYXoivuBwkKJ+MACi8tNi6e36BcAgAAuQACAAGifgIACijaAgAGy/QCAAC4rAIAABnyAgAAj1ID//9+iAIACTqGAgABvJYA=
Date: Wed, 18 Dec 2019 10:01:51 +0000
Message-ID: <e09fefbc-7ec3-a1dd-1bb7-dc5523eab886@omnitor.se>
References: <DB6PR0701MB24219718E7408022DB6F256493550@DB6PR0701MB2421.eurprd07.prod.outlook.com> <1b757fea-b5ce-c498-8100-cb54a4a431fa@omnitor.se> <5FF684F2-955E-4E52-AED5-69D9EA8D39F5@ericsson.com> <dc08b134-7c31-e466-3fcd-287105c1f455@cisco.com> <9e4f0999-0e06-d60d-c160-d95726288d5e@omnitor.se> <764C4101-0BFC-4379-8AA8-A4437992CB20@ericsson.com> <d5189a45-4398-5a4e-6eb0-ac5ec257b3d0@cisco.com> <bbd6694b-d98d-3e85-7996-cdf90033f3f4@alum.mit.edu> <954EC6EE-3F2A-4BD5-BEEB-7BE920A9DE67@ericsson.com> <8dae9394-635b-e2c7-0a72-8ab399daab4d@alum.mit.edu> <1e2dad90-10ab-47cc-8c38-06ef7f40d348@cisco.com>
In-Reply-To: <1e2dad90-10ab-47cc-8c38-06ef7f40d348@cisco.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: AM4P190CA0004.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:56::14) 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: 4047ebc0-8e60-48b0-0e17-08d783a14e09
x-ms-traffictypediagnostic: VI1P193MB0527:
x-microsoft-antispam-prvs: <VI1P193MB05270EC329844AFDF79A0D87FB530@VI1P193MB0527.EURP193.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0255DF69B9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(346002)(376002)(39830400003)(366004)(51444003)(189003)(199004)(2906002)(316002)(52116002)(8936002)(85202003)(31686004)(86362001)(31696002)(110136005)(53546011)(36756003)(6506007)(85182001)(66476007)(64756008)(66446008)(8676002)(71200400001)(2616005)(6486002)(66574012)(4001150100001)(966005)(508600001)(6512007)(5660300002)(66556008)(81156014)(186003)(81166006)(26005)(66946007); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P193MB0527; 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: BCL:0;
x-microsoft-antispam-message-info: mHM98jiDy7Wl97d99ZlL00xL+JQsVpXSjnpfYGG/kLbKMbDjwbsTbzuEAc8FEuUBzs9m5r3298xepD5oT4T2YceEZ/4YFE/UkAUTsySKIOKFWcyiNhDBFGlDX1+jn/ADrRQP1+8Y1NiYWotk7e1AKOmK0C1NOcP6HxJmrAq9z+QNXV3LJCV7lPRyHaj6yPW/ZT6Dsrrem16bUMx5xFfJtlH5DDcIUXhhC0mczi3rJypssVLtbYNQ0JSzCGNMgsC7yaCFwkC8FwByJVPrWdmwIYnMVQ2gGGjQ6zbOeMsEsAZJTIR6LG2Go6izBq5z+ZrAwIdfeqSdIlEOPJ2FcUh4DBlpS4smkOIZwF8HiJ9qIf5Rzv6Pba9yTMTbV0NRG9f3ce/DOTfiNyd8KppwR4MpHb7r7+HAspu5ht9hPK5+Qs/ihyPACCt+s69G7881hjbumWD2wDSx7cuB1DogsFW6RPvEVVB+m+U8lQHh+dRMjd6tONmkcyFc4s1K/WJEB0nPlpva39WkHbiLFKxJhTNTiGIaPUJPadeEpmZvGgCdctw=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_e09fefbc7ec3a1dd1bb7dc5523eab886omnitorse_"
MIME-Version: 1.0
X-OriginatorOrg: omnitor.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 4047ebc0-8e60-48b0-0e17-08d783a14e09
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2019 10:01:51.9628 (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: ZcKhYgEqRs6xKUqJ4/gzgQcoRl533lsfyKoREMbuRg2NoPEEy05MLBI/jD8vw+M8kjiC7LxHjaNNol/Xfq8fjuZNFGD6l1aW1EDdttOkBdc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P193MB0527
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/cEq33l4QRaEvbTCSgCm1NjMUauQ>
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: Wed, 18 Dec 2019 10:02:00 -0000

Den 2019-12-18 kl. 04:23, skrev Flemming Andreasen:


On 12/16/19 11:09 AM, Paul Kyzivat wrote:
On 12/16/19 11:05 AM, Christer Holmberg wrote:
Hi,

I'd be ok with the subchannel identifier.

I do think it would be good to add some generic text to sdpneg, though, saying that whenever the media description format or PT number would normally be used in an attribute (e.g., the fmtp attribute), when encapsulated in a dcsa attribute the subchannel identifier is used instead.

+1
Agreed as well.

-- Flemming

Yes, but not mentioning that the media description format or PT would be normal, because already rfc4566bis section 8.2.2 recognizes that fmt in the media line may be something different for other protocols than rtp and udp:

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

And also rfc4566bis section 5.14 about the media line does the same:

"

      For media using other transport protocols, the <fmt> sub-field is
      protocol specific.  Rules for interpretation of the <fmt> sub-
      field MUST be defined when registering new protocols (see
      Section 8.2.2<https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-32#section-8.2.2>)."




"

In rfc4566bis, section 6.15, fmtp is specified, and there "fmt" is used for the format value and it is said:

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

draft-ietf-mmusic-sctp-sdp correctly registers webrtc-datachannel as a valid value for fmt.

So far, this applies to the real media section directly in sdp

Now, sdpneg seems to create a second level of media sections multiplexed on the webrtc-datachannel format,
with some m-line contents in the dcmap attribute and the sdp attributes of the second level media section in the dcsa attributes.

I think that sdpneg might need to recognize this mapping from DCMAP and DCSA to a "simulated" media section more clearly.
Otherwise, the statement about fmtp in rfc4566bis "The format must be one of the formats specified for the media." will seem to be obstructed by sdpneg.

So, the mapping from media section to sdpneg parameters would be:

 m=<media> <port> <proto> <fmt> ...
<media> - undefined.
<port> - from DCMAP <port> parameter
<proto> - webrtc-datachannel
<fmt>   - from DCMAP <subprotocol> parameter     (only one allowed )



 a=<attribute>:<value>

<attribute>:<value> - from DCSA <attribute> parameter

Then the mapping from <subprotocol> to <fmt> for fmtp would follow automatically.


There are traces of this thought in sdpneg.

sdpneg recognizes that usage of attributes may need to be different when applied to a WebRTC data channel with the following insection 5.2.1:

"

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

   SDP attributes that are only defined for use at the dcsa usage level,
   SHALL use the dcsa usage level when registering the attribute.  If
   existing media attributes are used in a datachannel subprotocol
   specific way, then a new dcsa usage level MUST be defined for the
   existing media attribute.  Where the SDP attribute is applicable to a
   particular subprotocol/s this SHALL also be registered by indicating
   the applicable subprotocol identifiers (see
   /[I-D.ietf-mmusic-rfc4566bis<https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-28#ref-I-D.ietf-mmusic-rfc4566bis>] section-8.5) along with the dcsa usage
   level.


"

It might be sufficient to add a sentence in this area, saying something like:

"The fmt parameter in dcsa attributes shall have the same value as the subprotocol in the corresponding DCMAP attribute."

Or a more thorough description of the mapping of the media section as described above.

Will there be a need to IANA - register the use of each subprotocol as belonging to the namespace of <fmt> for the webrtc-datachannel protocol to be true to the registering requirements from rfc4566bis?

Regards

Gunnar



Regards,

Christer


On 16/12/2019, 17.58, "mmusic on behalf of Paul Kyzivat" <mmusic-bounces@ietf.org on behalf of pkyzivat@alum.mit.edu><mailto:mmusic-bounces@ietf.orgonbehalfofpkyzivat@alum.mit.edu> wrote:

     On 12/16/19 10:34 AM, Flemming Andreasen wrote:
          >> Also, I think we should aim at being aligned with the RTP usage when it comes to SDP attributes.
     > Agreed again. I think the "fmtp" attribute is the right one to use here
     > - the question is simply what format value we use. I'm leaning towards
     > "t140", but we should get some general text in sdpneg to account for
     > additional media formats in the future.
          IIUC you are proposing that the format value in fmtp attributes for data
     subchannels should be the subchannel identifier. Is that right?
          While that is redundant I won't oppose that.
              Thanks,
         Paul

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

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


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




_______________________________________________
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