Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: Semantics of same port in multiple m- lines
Roman Shpount <roman@telurix.com> Mon, 01 February 2021 17:43 UTC
Return-Path: <roman@telurix.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 9EC853A134A
for <mmusic@ietfa.amsl.com>; Mon, 1 Feb 2021 09:43:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
header.d=telurix-com.20150623.gappssmtp.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 n9vY9cbhHjgo for <mmusic@ietfa.amsl.com>;
Mon, 1 Feb 2021 09:43:30 -0800 (PST)
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com
[IPv6:2607:f8b0:4864:20::332])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 7EDDB3A1348
for <mmusic@ietf.org>; Mon, 1 Feb 2021 09:43:30 -0800 (PST)
Received: by mail-ot1-x332.google.com with SMTP id f6so17093131ots.9
for <mmusic@ietf.org>; Mon, 01 Feb 2021 09:43:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=telurix-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=rzrCow2BQAK+z5dq70gO8bnvfuV8EytIzpeVZw26arI=;
b=LeyebpcTpz3+oepSrURfO7rvFaaiH/YKve0Y5KLpgAkHqX7eFs9GjJ0uv3MKHKdt5A
dKH2tBBffeMxmpc8UF8lhdkcsAZD8bzsBwn/aUTDbnPUu58ZkcCLshsp9doKW2RFdrVe
ux3uxoZpFd84tBJNp5SBmj/TZ+n92eVzj5ZB8on9uWb4Ny16d1GFh59h5eCtDJrgZFLc
Ev4w0nC5YrvfDq4kK6WxPUa4DI8z6vuiOuvZt4ydTlI/sdoF15pzm4k5D2vPIojlbUlm
nFYR+KFT5HcxliJKGejO9P/afNBipIxpechil+peRK1+K27hNsmXHAmS3vVvPBZ9SjdI
LmaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=rzrCow2BQAK+z5dq70gO8bnvfuV8EytIzpeVZw26arI=;
b=sIkQ3L6A6nq0Ew/se0b7b3PfwIpsgs57oITmYQjB2O6yzqQklOUAHbrjXYIk8EiBGr
z02LHTKzbRHf/fk4so3OQjh6qwUf6KYD2Z03uX2VTzR+1ZHBxy4NNfWdVsamDnkBdpr0
SGmKzJU+Cl8rUPx+mWAYU6xJAk+E+8r6tn3JVEJz6hMfCWLBAHn1eTMCHKk05ciSRucH
ToeM+aajs3lvlXCvbzEr+lt6J8tMfsPyWYIiGO5o+rNGutbrFShOuYcrsMleJj5qoH3U
3zPsXtS+iKG+Oa6onZNuwvIGGA7XRNpFtalWzAqgCBZJLDqjzQNVI8RDEnCzyons2arb
nMGg==
X-Gm-Message-State: AOAM533W4t9Yk2B4V0N/iLyBDpKiuCLkn37+bejIIUW7/Tk8zgdldb9Y
+ukz0bvD/Gx0faSZcIf6tuXOLJOFqrXwRA==
X-Google-Smtp-Source: ABdhPJwdFxTMEvUEzhg6CXsiimH2KR94TcgCODf65Eo/BOGKJCTwKjdpJHi5imLFQrdP2KOmahspKw==
X-Received: by 2002:a05:6830:4b1:: with SMTP id
l17mr11911813otd.119.1612201408927;
Mon, 01 Feb 2021 09:43:28 -0800 (PST)
Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com.
[209.85.167.179])
by smtp.gmail.com with ESMTPSA id e11sm3718216otp.15.2021.02.01.09.43.28
for <mmusic@ietf.org>
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Mon, 01 Feb 2021 09:43:28 -0800 (PST)
Received: by mail-oi1-f179.google.com with SMTP id n7so19635513oic.11
for <mmusic@ietf.org>; Mon, 01 Feb 2021 09:43:28 -0800 (PST)
X-Received: by 2002:a54:4512:: with SMTP id l18mr32650oil.12.1612201407808;
Mon, 01 Feb 2021 09:43:27 -0800 (PST)
MIME-Version: 1.0
References: <AM0PR07MB3860A872DE7E09ED79FE4EAD93BA9@AM0PR07MB3860.eurprd07.prod.outlook.com>
<CAD5OKxuvMzNGHnk2tGM9yjUBYz9EGdEj8kNO=a4d-SiBiA42jA@mail.gmail.com>
<AM0PR07MB38600ED79AA323A8C38098AB93B99@AM0PR07MB3860.eurprd07.prod.outlook.com>
<CAD5OKxsLL=+DLu-D2y-rOFGMDpKXgsWhVDFLiWS1k68LhwU8Dg@mail.gmail.com>
<AM0PR07MB3860D4EC744D231497EFA5F993B89@AM0PR07MB3860.eurprd07.prod.outlook.com>
<CAOJ7v-0juBeH3g4MY6jSj+pRnk6+CBFt24p9jFQ+Fwd4qjp_nw@mail.gmail.com>
<AM0PR07MB38600147C590A3D84054036D93B89@AM0PR07MB3860.eurprd07.prod.outlook.com>
<CAOJ7v-2oL-YP=CGUkCZ8NuP5xPur0z+BK3qZZTdHCNxQZ16HqA@mail.gmail.com>
<AM0PR07MB38609424137713FAA193CAE193B79@AM0PR07MB3860.eurprd07.prod.outlook.com>
<CAD5OKxshWvy69fs5tgrME9CT6YV6eaqR3K5w8mOQEnm0CcyMpw@mail.gmail.com>
<AM0PR07MB3860F88FFE187446FBDB786193B69@AM0PR07MB3860.eurprd07.prod.outlook.com>
<49cd0938-1f48-8a00-69b0-8063b99282b3@alum.mit.edu>
<AM0PR07MB3860F7CF9926F51856AD5FED93B69@AM0PR07MB3860.eurprd07.prod.outlook.com>
In-Reply-To: <AM0PR07MB3860F7CF9926F51856AD5FED93B69@AM0PR07MB3860.eurprd07.prod.outlook.com>
From: Roman Shpount <roman@telurix.com>
Date: Mon, 1 Feb 2021 12:43:16 -0500
X-Gmail-Original-Message-ID: <CAD5OKxv728xY42iv39wA1EW3XUw-LPRDKAG=6-Jr67mA=sBfhw@mail.gmail.com>
Message-ID: <CAD5OKxv728xY42iv39wA1EW3XUw-LPRDKAG=6-Jr67mA=sBfhw@mail.gmail.com>
To: Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000380a9405ba49e410"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/zWngLwzZOfH3ehSdgxmHKp9hoOI>
Subject: Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: Semantics of same
port in multiple m- lines
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, 01 Feb 2021 17:43:33 -0000
On Mon, Feb 1, 2021 at 12:27 PM Christer Holmberg <christer.holmberg= 40ericsson.com@dmarc.ietf.org> wrote: > >>>> Sure, we could have done that. However, as has been discussed that in > the past (in MMUSIC, SIPCORE etc), we typically don't describe situations > that can occur when endpoints behave strangely, because it would easily > become a slippery slope. > >>>> Also note that, in addition to bundle-only there can also be other > attributes that have been copy/pasted by the remote endpoint. > >>> > >>> This is not "endpoints behaving strangely". This is the expected > behavior of an endpoint that does not support bundle. > >> > >> I don't think copy/pasting attributes you don't understand is expected > behavior. That in general can cause lots of problems. > >> > >> But, I do buy the argument that some endpoints do that, and that it is > not (as far as I remember) explicitly forbidden. > > > > Shooting yourself in the head isn't AFAIK explicitly forbidden. But > unless you understand and desire the consequences it is generally an unwise > thing to do. > > > > I don't think an IETF document is obligated to protect against people > doing either. > > > > Also, if we have an implementation that doesn't support bundle that is > copying an a=bundle-only it doesn't understand, won't it also likely be > copying a=group:bundle and a=mid??? > > My understanding was that it only affected media-level attributes. > > But, sure, in theory an endpoint could copy ANYTHING it doesn't > understand... > The issue is how does an endpoint generate an m= line to refuse something that the endpoint does not understand. For instance, the endpoint gets an application webrtc-datachannel m= line but has no idea what any of the SDP attributes mean and which ones are required to form a valid m= line. The simplest way is to refuse such an m= line was to copy the entire m= line in the answer and set the m= line port to 0. As far as the endpoint is concerned, there is no difference between a=sctp-port or a=bundle-only, if neither are supported. If this is an invalid procedure to refuse an m= line, please point out where it says this is invalid and let me know where the correct procedure is described. Session level attributes are different since this is something that is negotiated, it would be logical not to include them if the endpoint does not support them. _____________ Roman Shpount
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Christer Holmberg
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Roman Shpount
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Christer Holmberg
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Roman Shpount
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Christer Holmberg
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Justin Uberti
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Christer Holmberg
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Justin Uberti
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Roman Shpount
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Justin Uberti
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Christer Holmberg
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Roman Shpount
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Christer Holmberg
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Paul Kyzivat
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Christer Holmberg
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Roman Shpount
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Christer Holmberg
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Paul Kyzivat
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Roman Shpount
- Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: S… Christer Holmberg