Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt

Roman Shpount <roman@telurix.com> Fri, 29 October 2021 18:08 UTC

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530863A1532 for <rtcweb@ietfa.amsl.com>; Fri, 29 Oct 2021 11:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=telurix.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 SvueacjKb0n1 for <rtcweb@ietfa.amsl.com>; Fri, 29 Oct 2021 11:08:29 -0700 (PDT)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 700973A1530 for <rtcweb@ietf.org>; Fri, 29 Oct 2021 11:08:29 -0700 (PDT)
Received: by mail-qk1-x72b.google.com with SMTP id i9so9651415qki.3 for <rtcweb@ietf.org>; Fri, 29 Oct 2021 11:08:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ApNoVeVyd89RwkvJyF7pUtQk+bTJO7mfDBu5vukDBs0=; b=CvOyTs5G+q8uwrrsWPu0H1p909q7i+BO2IKeBJXrHo8xsesrK7wxp/NUsImrySbAxN 5uF7tL69H6kIjlAIwovzKgpEkE8ah9GmEtc9C4SN2qBBEhC/12n4MtmQqxiN2o39LYpy GcjSNGZw55Bf00XhTcdydXIpRC6lYasqyEcaU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ApNoVeVyd89RwkvJyF7pUtQk+bTJO7mfDBu5vukDBs0=; b=AWlBSh86C+LNxdbsSzcEvIvDCKB3NafKqOncXwQaftdyS2ohripdi/c+KyeY519ie0 uhGgySPHH+gxGVeRyMFyRkPda2ZoWh1RWKWIJsK+iPpD+FlFoPHwUvWqYD2yfFuS7lhX df0FTQkxEFZQHAwG/J8871rpxIcyBYsZmNzr7cANNOFKsdOTHo58Avojmb8gVkUoqx6/ DFaXapVckTX1mUygrDldiBaSzxER+HaedhR+ha+dsem6Wm493MP9K+EkH2+QOqeapJpU 8jAc+cG14JbQEDL44XUpi3IPQ2ij6z9ZV3bDlekRcQMzxsGrjb0gl1v250VDzStoPjij UrJw==
X-Gm-Message-State: AOAM533PUekFQW/I63hiv4CJFaxauxRBNH/MJSuIyNcuAWzfTmjJGNvS ETbQw11O452QYgStyoH7o4YiMx4ALe1a1Q==
X-Google-Smtp-Source: ABdhPJxzTMgwVyNEalHOEsdzj4MJLm9RFa3AodLl3FLqqYZoC+6pEOkN++jmT2YqHdf6T2hV1TVqEQ==
X-Received: by 2002:a05:620a:4706:: with SMTP id bs6mr10147321qkb.122.1635530906890; Fri, 29 Oct 2021 11:08:26 -0700 (PDT)
Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com. [209.85.219.173]) by smtp.gmail.com with ESMTPSA id i22sm4777982qkn.80.2021.10.29.11.08.26 for <rtcweb@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Oct 2021 11:08:26 -0700 (PDT)
Received: by mail-yb1-f173.google.com with SMTP id d10so15392416ybe.3 for <rtcweb@ietf.org>; Fri, 29 Oct 2021 11:08:26 -0700 (PDT)
X-Received: by 2002:a25:f205:: with SMTP id i5mr13372357ybe.61.1635530905879; Fri, 29 Oct 2021 11:08:25 -0700 (PDT)
MIME-Version: 1.0
References: <CA+9kkMA_8jCGeb_QkhVz2JLRYGbq+MkGG9wJ2k0vo6noDDkkQA@mail.gmail.com> <CAD5OKxvK_CUnHc0kqNNVUkOHgtUqL=vjdUTLqL+RJpZBtWL+4A@mail.gmail.com> <CALe60zAC7VA6y5oLkC9HBRQUhJyY73Atbfmm1KVKw=hyPqD=2Q@mail.gmail.com> <CAD5OKxvi7t6ug9xsjqiB35hTWNJ0D04XK5w=njZ8hB_6UpRzEQ@mail.gmail.com> <CAOLzse14Qkn+EiO3xHfGi2QmBvH0M=fQD-SmA9TXsfmHjPKLfQ@mail.gmail.com>
In-Reply-To: <CAOLzse14Qkn+EiO3xHfGi2QmBvH0M=fQD-SmA9TXsfmHjPKLfQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Fri, 29 Oct 2021 14:08:15 -0400
X-Gmail-Original-Message-ID: <CAD5OKxtrBFsZBGUKtB6MNwMrPnzE9NSyQWrjXGjzE8PkYmj8Bw@mail.gmail.com>
Message-ID: <CAD5OKxtrBFsZBGUKtB6MNwMrPnzE9NSyQWrjXGjzE8PkYmj8Bw@mail.gmail.com>
To: Justin Uberti <juberti@alphaexplorationco.com>
Cc: Justin Uberti <justin@uberti.name>, RTCWeb IETF <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000aa074405cf81b682"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/SjzHJYcq53CKlYhBfNbdsWYqPnA>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2021 18:08:34 -0000

On Fri, Oct 29, 2021 at 1:35 PM Justin Uberti <juberti@alphaexplorationco.com>
wrote:

> On Tue, Oct 26, 2021 at 3:06 PM Roman Shpount <roman@telurix.com> wrote:
>
>> Regarding 3PCC, bundle clients should be able to accept the initial offer
>> without bundle-only. Unfortunately there is nothing there that prevents
>> them from moving an m= line out of the bundle unless it is marked with
>> bundle-only.
>>
>
> If it's already bundled, I don't think it can be unbundled, since there is
> no other transport to move it to. This is the same situation as in
> subsequent o/a exchanges.
>

It is correct that m= line cannot be unbundled once it is bundled. If this
offer is received as a result of 3PCC, there is nothing in the offer that
indicates that the m= line cannot be unbundled.
Per draft-ietf-mmusic-rfc8843bis section 7.3.2 (
https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-moving-a-media-description-
):


   - In the corresponding offer, the "m=" section is within a previously
      negotiated BUNDLE group, and
      - In the corresponding offer, the "m=" section contains an SDP
      'bundle-only' attribute.

If either criterion above is fulfilled, the answerer cannot move the "m="
section out of the BUNDLE group in the answer.

For subsequent offers processed as initial offers neither of those criteria
are true. There are no previously negotiated BUNDLE groups (it is an
initial offer). There is no 'bundle-only' attribute. Because of this, even
a bundle aware endpoint can move the m= line out. There is no requirement
to check that bundled m= lines are using the same address/port.


> I was not thinking about the frequency of use of 3PCC with non-bundle
>> endpoints (extremely rare) but about the use of 3PCC in general (more
>> common and hard to identify).
>>
>> I agree that a=bundle-only is insufficient. We do need to add port zero.
>> This will ensure that a bundle-aware endpoint will not take the m= line out
>> of the bundle. If 3PCC with a non-bundle-aware endpoint is likely, the
>> application should create a new PeerConnection instead with an appropriate
>> bundle policy.
>>
>
> As noted above I don't think taking an m= line out of the bundle is
> allowed when a shared port is already in use.
>

As I am trying to explain, there is nothing in the offer that would
prevent the compliant implementation from moving the m= line out. This is
not obvious but can cause grief.
_____________
Roman Shpount