Re: [MMUSIC] AD Review: draft-ietf-mmusic-t140-usage-data-channel

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Mon, 27 January 2020 20:13 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 F08FF3A0B7B for <mmusic@ietfa.amsl.com>; Mon, 27 Jan 2020 12:13:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, T_SPF_TEMPERROR=0.01, 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 pfcUGMmExWxi for <mmusic@ietfa.amsl.com>; Mon, 27 Jan 2020 12:13:33 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80117.outbound.protection.outlook.com [40.107.8.117]) (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 8EEB23A0B79 for <mmusic@ietf.org>; Mon, 27 Jan 2020 12:13:31 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iu+nKKfh+cTRVyClcSeYYICbhFuiztDluMyuSya256aL+BNjFm3yMNBewvCITtajwzErAkyt5AvVarIJoHlozgCjtAp6wW2j0XLdUyhy6FIN1mu27f0SFEKWCjlYGYdveC3UetTP+wv6EqqiyMQIbI+iwwI0BnIEgx3Ad8LK88QRBqdNTonLB2rbzG7rSLJTfs/MsdqgXnvxdpj9UniW2IUrgQPXse4lenH+XPQ9xRpgWGkjq4JspOLtSEXtubOR5KYhgkD0skWM5Zyncq/Dgo9S35i/qf6IjHk2YENSrq4a3NZjluXYi5HfeOU9kBqwAgutKJ1xzjRrupzVsP/R1g==
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=8jGBaqmIo5ACrY857nYZ4u5yh6GB1kB9lruZL2WETcI=; b=U1DYgaeBu/jynhuCfZUfF/8YyAWwgESMlecTdKgCPo05BeCLh8KRfGRtgF+aNS5hKWv+AgOPgqQ8Wt+tpO9suOj43V3TciDKz7cRiv0oup9fT1rY+xqqBPMR367ckJ1uJrcFDfVwP/QErYdi8atXD9PVqXgbBQw5krsBeT1GELLhpq0WJITpUcmTPO98g0+HRGLcszGa77jRX/q3BpdZFHdGRVZag9sW9rB4t4hYEYhmi2/fy1Qiq9c/bZ32GTXqqXqKsY0n1EDHdnmg/GDG5dIS8SZtSMuQilnA3aepCemr0v7ePRkAdJQF8V7tRsyGVwawhUArNsButgcQ/AID7A==
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=8jGBaqmIo5ACrY857nYZ4u5yh6GB1kB9lruZL2WETcI=; b=ohfa99JqHGYURlOvvSK+f++touki9+xC61jhSr/7pkd7i50yx4j3okPGIntCpU9LgraCHfAK87mocR8hzZ4OV9j3Yf3B4wCYjZYvovMor6T98A2JzGkg4Nl8FyVBNkbv+eBE+gwnxQK8hHXqMUbV+mjSzsxDOXvvKNq6TUtg/Lw=
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM (10.186.178.76) by VI1P193MB0335.EURP193.PROD.OUTLOOK.COM (52.134.122.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.23; Mon, 27 Jan 2020 20:13:23 +0000
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::1910:128d:b820:f765]) by VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::1910:128d:b820:f765%4]) with mapi id 15.20.2665.026; Mon, 27 Jan 2020 20:13:23 +0000
Received: from [192.168.2.136] (77.53.230.59) by ZR0P278CA0026.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:1c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.21 via Frontend Transport; Mon, 27 Jan 2020 20:13:22 +0000
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] AD Review: draft-ietf-mmusic-t140-usage-data-channel
Thread-Index: AQHV0red4pHVd2FrJkakQFnaNtlEz6f9GJqAgAAUaQCAAComgIABVLyAgAAFN4CAAAWzgIAAHZgAgAAY8ICAAAmogA==
Date: Mon, 27 Jan 2020 20:13:23 +0000
Message-ID: <2afe4f38-0b14-5991-e2df-d5ffd2d001c1@omnitor.se>
References: <25e5fd92-84c2-fd6c-d497-3fcfa452967e@nostrum.com> <556B5E81-09BE-41E4-9A2C-E902E870F0E0@ericsson.com> <715526dd-fa80-ea2b-5837-aa08193b7445@nostrum.com> <9C2BD899-6EC8-4920-96AC-6C2B170B6373@ericsson.com> <60b0aaa0-648d-4026-1820-9322743d7778@omnitor.se> <DB0C4D76-E849-4609-847E-6E454F14B7BC@ericsson.com> <659c43b1-7fa7-3bf4-0b9a-3dfa6ecaad93@omnitor.se> <8ee7d5b1-131c-9e47-4026-d64a8b0ba0c6@alum.mit.edu> <BBC0E0FA-99D0-48CB-9D35-DBAB0739D90B@ericsson.com> <f5db2705-7043-7dbf-0cb4-daed062882a6@alum.mit.edu> <AA322B3E-ECAD-4F94-8DC7-EB4715B0B6C8@ericsson.com> <d1a40c44-0378-1e1f-f1a4-576e6232c924@alum.mit.edu>
In-Reply-To: <d1a40c44-0378-1e1f-f1a4-576e6232c924@alum.mit.edu>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: ZR0P278CA0026.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:1c::13) 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: 9224c30b-41ce-4563-11fd-08d7a3655c20
x-ms-traffictypediagnostic: VI1P193MB0335:
x-microsoft-antispam-prvs: <VI1P193MB0335EEFEFA10619743225FBAFB0B0@VI1P193MB0335.EURP193.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02951C14DC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(396003)(346002)(39830400003)(376002)(199004)(189003)(5660300002)(316002)(53546011)(2616005)(31696002)(81166006)(956004)(81156014)(26005)(86362001)(8676002)(16526019)(71200400001)(186003)(8936002)(16576012)(6916009)(36756003)(966005)(508600001)(31686004)(66446008)(2906002)(66574012)(6486002)(66556008)(66946007)(64756008)(66476007)(52116002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P193MB0335; 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: qWdhOTEGaHR+jrgKKXU83D96wBZy21TNDwyfkyzUBBOSln+AQD/RGe4wMgAdNxTRqc90nLd2qaoXqwIuR7wWMrDVey5CQS+cloaDHBg55HEeoQk9KCOhZ5CuaARCr+XmVdK2j3js5/B2jvDwhSiKQcjySP+apOVOPm4yMMMoeBlrda0StRckGbsh/XKb9S/0EbmTAw91K820amWJyc8Rn2BB2VC/WsaPFQS36YOkMXp3g+1nXjSKuoGew4PBBoTwFPvzPJK4Q/GX2QkyWtITKpeHPfRU5fEr/nEISsO3BRUsU5RyTgwXzrW561GFxvS/hQCIIcfXsRofvjWSUdiTBdA3FIiC5/N4BCkFC/qOjD5XwzHCq7t6dcB2U239OJ/o77U5Wg8NxEQ+iOPxWhxRwcxLDH8ao2Zs+KD/ClLgptSLSPs6fz+3MDTCiRkGh3Dxuhp7KfDU06Tkrff2cLGMoJmAIqSEgtSImRiEjPaQkJ+gPDsJTFaLeWRiv0JlMIoBMbdBOxlwxtPkZhn1EesZEw==
x-ms-exchange-antispam-messagedata: WBei13SiL5GPIFgjlyL0ZL1BTgYU5lKAxFcjKXojUjdrbkl2P+TQUYvmOE0iB3J+LqUMbXVoMq5PMSKOk2nkpwLx3qrCygRxItDMryNSkAyfBvXT60hqguX5SKschNp21YkUltYyxOj6TQP/6JmAcA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_2afe4f380b145991e2dfd5ffd2d001c1omnitorse_"
MIME-Version: 1.0
X-OriginatorOrg: omnitor.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 9224c30b-41ce-4563-11fd-08d7a3655c20
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2020 20:13:23.0527 (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: 2u8sT5cgSs+t+LeFNlgOf+3VxACuccLhNc+eVYXS+hIIw+IvWGa5oACFwAiBaVK7l3lVlzT6cXJHqi1cDxU1gdRbGyPKx7W0wZevOP2DQwY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P193MB0335
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/jn64JC-W5KssBG-cVsgbrXRqlmk>
Subject: Re: [MMUSIC] AD Review: draft-ietf-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: Mon, 27 Jan 2020 20:13:38 -0000

Hi,

Den 2020-01-27 kl. 20:38, skrev Paul Kyzivat:
On 1/27/20 1:09 PM, Christer Holmberg wrote:
Hi,

     >>>> sdpneg has the following wording in 6.2 for the error case when both
     >>>> parameters are included in the answer:
     >>>>
     >>>>    "If an SDP answer contains both
     >>>>     of these parameters then the offerer MUST treat the associated SDP
     >>>>     offer/answer as failed."
     >>>
     >>> The tricky part of treating the O/A as having failed is that only the
     >>> offerer knows this, while the answerer thinks it has succeeded. So the
     >>> two sides have differing understandings of the state of the session.
     >>> (Consider that there may also have been changes in another media
     >>> section.) Things will not go well until this is corrected.
     >>>
     >>> I don't know if there is any document that specifies what to do in this
     >>> situation. I think there are only two generic possibilities: drop the
     >>> entire session (i.e., BYE), or start another O/A to try to fix this,
     >>> perhaps by dropping the m= line. When following this latter course,
     >>> there will be an extended period while the two sides are in
     >>> disagreement, and no guarantee that the fix will work.
     >>>
     >>> The simplest solution is to simply say that this is a protocol
     >>> violation, and recovery is an implementation issue. While simple to
     >>> write, this is perhaps not the best solution.
     >>
     >> That is normally what we say.
     >>
     >> However, if more text is needed I think it belongs to the data channel sdpneg draft. I don't think that each data channel usage draft shall have to describe how it is done.
     >
     > Then I think the best path might be to update sdpneg with some specific
     > language, and then update this draft to refer to that.

We can do that. However, we don't need to wait for that until we progress this draft. It is anyway not going to be published until sdpneg is done.

The only concern is that I think there ought to be a reference to whatever sdpneg will say on the subject. But perhaps it is possible to craft a reference that works assuming that sdpneg will be updated, without waiting for that update to be made.

sdpneg has wording for a specific case of failure in section 6.5:

6.5.  Offerer Processing of the SDP Answer

   An offerer receiving an SDP answer performs the following:

 o  SHALL close any created data channels as described in
      Section 6.6.1 for which the expected "a=dcmap:" attributes are not
      present in the SDP answer.  If the SDP answer has no "a=dcmap"
      attribute either the peer does not support "a=dcmap:" attributes
      or it rejected all the data channels.  In either case the offerer
      closes all the SDP offered data channels that were open at the
      time of offer.  The DTLS association and SCTP association will
      still be setup.  At this point the offerer may use DCEP
      negotiation [I-D.ietf-rtcweb-data-protocol] to open data channels.

---------------------------


A change in this section can include more cases.
Proposed NEW wording:

6.5.  Offerer Processing of the SDP Answer

   An offerer receiving an SDP answer performs the following:

 o  SHALL close any created data channels as described in
      Section 6.6.1 for which the "a=dcmap:" required attribute or values
      in the SDP answer are missing or malformed.
      If the SDP answer has no "a=dcmap"
      attribute either the peer does not support "a=dcmap:" attributes
      or it rejected all the data channels.  In either case the offerer
      closes all the SDP offered data channels that were open at the
      time of offer.  The DTLS association and SCTP association will
      still be setup.  At this point the offerer may use DCEP
      negotiation [I-D.ietf-rtcweb-data-protocol] to open data channels.
---------------------------
Regards
Gunnar


    Thanks,
    Paul

Regards,

Christer



_______________________________________________
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