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