Re: [MMUSIC] A corner-case: Rejection/change of bundle tag, bundle-only, and trickle ICE

Taylor Brandstetter <deadbeef@google.com> Fri, 24 February 2017 19:08 UTC

Return-Path: <deadbeef@google.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 5EBBE1294D1 for <mmusic@ietfa.amsl.com>; Fri, 24 Feb 2017 11:08:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ooElj6V50i92 for <mmusic@ietfa.amsl.com>; Fri, 24 Feb 2017 11:08:00 -0800 (PST)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 789AB1294CF for <mmusic@ietf.org>; Fri, 24 Feb 2017 11:08:00 -0800 (PST)
Received: by mail-qk0-x22d.google.com with SMTP id x71so26641788qkb.3 for <mmusic@ietf.org>; Fri, 24 Feb 2017 11:08:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4vWKDP0j9aiXwvcK0TR+y85bSJ9huM0G/7crqa5fB0g=; b=BVH2Q26WonoMHI8KUyVJglIGyfKCZgNKVrOUlucobElZO0qrWtBXqXhNIZbYNMiCle TEHym0atKkrh+5adywsYlP/IPOXDyPci7/KVoUtXQ63JguXExWqTUi/sCcFpvVjLCngO TIL2jVvt6yPGDTD5yetijoneQ1q7Cd+vQf/5XwyrZQ4RDn4BlQR2m0UYECIJeVUiz/KH eHTtghVi/fV0V3czL0V/aOD6xKgRjhM6y97by0V1WH3RtRC4DmHpSKE+p1k0uivoyJaw kGpfKqxC4MFUJ9yOT9NYFub2SJ9tRX/kibqiO8D/Rn2ggRl73JCFyCPmPfUc0nlbMJhD V8yA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4vWKDP0j9aiXwvcK0TR+y85bSJ9huM0G/7crqa5fB0g=; b=puTd/vRyXIQm2XsniJMH/isw/vuf9eMKR/raEx6kGis8JM7qmuYR4Wy9anKWEkgYLU QU128m4V4IY8/mda7YpmoCe9ldJ+XSNUkroVFbZjF6gAsbJ0QrXDrzcz0ILOBBWO0PSQ k20tK+5HBq7kDsaEHJTG+F40UxcjODK1bqvGF+b1nNpW9YYtIimCP9lCb5cbowU0eFUJ 5H4Qk9EdLp2R8IGxqLTslddET+drlQFctsWHU7mbCtbNWkxARi7sBLfk96Rb22ATfboa AfB0KFtQnZKWOUl1x9Wl5P3XRQmTK6+7+29Cv6ZfKEJ+bpfxh9VmAZUzqsmNIZt/VvKj WcRQ==
X-Gm-Message-State: AMke39lLCxNv3jVcHW60kPoZiYhdhwoJoCFS7rrnhqa9htwZPCycbO6aiNRWqLq4Dk35DWE6fNQYBaA1johx/T/r
X-Received: by 10.55.166.81 with SMTP id p78mr4245426qke.142.1487963279246; Fri, 24 Feb 2017 11:07:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.38.163 with HTTP; Fri, 24 Feb 2017 11:07:58 -0800 (PST)
In-Reply-To: <73e087ca-a179-a571-0431-d580392e0439@gmail.com>
References: <73e087ca-a179-a571-0431-d580392e0439@gmail.com>
From: Taylor Brandstetter <deadbeef@google.com>
Date: Fri, 24 Feb 2017 11:07:58 -0800
Message-ID: <CAK35n0b3yUkp92NyWE9384zP7zpoXTn7iXzHcu+GeJ1JQqQu=w@mail.gmail.com>
To: Byron Campen <docfaraday@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c06e24cb3499805494b7292"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/dIJHuEs4C5TBCnXhwBVqCBp4xnU>
Cc: mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] A corner-case: Rejection/change of bundle tag, bundle-only, and trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 24 Feb 2017 19:08:02 -0000

> What happens if the answerer rejects mid 1? (2 seems reasonable?)

As currently specified: 2

> What happens if the answerer moves mid 1 out of the bundle? (2 seems
reasonable?)

As currently specified: 2

> What happens if the answerer rejects both mid 1 and 2? (Uh oh...)

As currently specified: This isn't supported.

I discussed these sorts of issues with Christer here:
https://github.com/cdh4u/draft-sdp-bundle/issues/21
And here: https://github.com/cdh4u/draft-sdp-bundle/issues/22

And the conclusion so far is, "you should make sure the m= section things
are bundled on isn't one that's likely to be rejected".

> What happens for combinations of rejecting mids, and moving them out of
the bundle? (Oh fun...)

Whichever one ends up as the "answerer BUNDLE tag", aka the first tag in
"a=group:BUNDLE" in the answer, ends up being used. And this can't be the
mid of something that was "a=bundle-only" in the offer (see above).

On Fri, Feb 24, 2017 at 9:16 AM, Byron Campen <docfaraday@gmail.com> wrote:

>     Let's say we have an offer like the following (very pruned down, for
> clarity). Note that it is using trickle ICE, and no candidates have been
> gathered yet.
>
> a=group:BUNDLE 1 2 3
>
> m=audio 9 ...
>
> a=mid:1
>
> ...
>
> m=video 9 ...
>
> a=mid:2
>
> ...
>
> m=application 0 ...
>
> a=mid:3
>
> a=bundle-only
>
> ...
>
>
> I see a couple of questions here about what transport (if any) mid 3 uses:
>
> * What happens if the answerer rejects mid 1? (2 seems reasonable?)
>
> * What happens if the answerer moves mid 1 out of the bundle? (2 seems
> reasonable?)
>
> * What happens if the answerer rejects both mid 1 and 2? (Uh oh...)
>
> * What happens for combinations of rejecting mids, and moving them out of
> the bundle? (Oh fun...)
>
>     From the signaling alone, it is not always clear to the offerer which
> mid the answerer has chosen to use for transport stuff, so saying the
> answerer chooses arbitrarily doesn't quite solve the problem. I suppose the
> offerer could wait for the first trickle candidate, and use the mid
> specified there (provided it is valid, which I'm not sure has been
> adequately specified...).
>
> Best regards,
>
> Byron Campen
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>