Re: [MMUSIC] Bundle offer with different ports - where to expect media?

Martin Thomson <> Tue, 28 May 2013 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 45E3221F9895 for <>; Tue, 28 May 2013 09:34:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tDUtrxAb2F6o for <>; Tue, 28 May 2013 09:34:54 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22a]) by (Postfix) with ESMTP id F14EE21F988B for <>; Tue, 28 May 2013 09:34:52 -0700 (PDT)
Received: by with SMTP id hr14so3389082wib.5 for <>; Tue, 28 May 2013 09:34:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qauuvAeuUbzYWSVsU/okVz/55GaEYdeKH9TvBn4sUU4=; b=G+I4PIxEG0emzOl7O9L5g2MuO0UaAbpjmiUopSZwwhM2wHlF5pYjjN9iu0mZ1tHIIv UhiB5R/1AS69NOnwURR8rc4MW6zBNMSYYsqG1DvmN6pc0DrY3QVDhU0+yULm2kUH1CI8 AJokQD15sEXEbXzmSf4z1deHG27Ugj9ToklMy9mBYt64uf5+5pJ+yjkiEMfpfLyjrvb3 tVbrrDGxWUqJiy8XVMIFBaPdVLJT9LdVbONuU43QUVGlbGWFy1gJw8ghJkFGNuM0vElB Y5epfL1pwjgyZvXMhEHIi5RS97Q+1I9Bh6/CtWpt0ESSH0iwYr64SH6SrqRBVkiRF8TA oTRw==
MIME-Version: 1.0
X-Received: by with SMTP id gf9mr12848698wic.32.1369758890950; Tue, 28 May 2013 09:34:50 -0700 (PDT)
Received: by with HTTP; Tue, 28 May 2013 09:34:50 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 28 May 2013 09:34:50 -0700
Message-ID: <>
From: Martin Thomson <>
To: Paul Kyzivat <>
Content-Type: text/plain; charset=UTF-8
Cc: "Cullen Jennings \(fluffy\)" <>, Christer Holmberg <>, mmusic <>
Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 May 2013 16:34:55 -0000

On 28 May 2013 09:16, Martin Thomson <> wrote:
> On 27 May 2013 08:47, Paul Kyzivat <> wrote:
>> no

FWIW, I can live with that.  (Sorry about the earlier empty email.)  I
was simply trying to be aggressively minimalist.

This model requires that each m-line has two independently negotiable
 - accepted/rejected (signaled using zero port)
 - bundle membership (signaled using a=group)

(and yes, this requires an update to 5888)

Then we need, as you describe, rules for transitioning between states.

Transition between accepted and rejected is always possible in both
offers and answers.

It seems like we are saying that bundle membership can transition in
the following ways:

Any group to no group:
 - In an offer, under all circumstances.
 - In an answer, if the m-line is rejected.
 - In an answer, if unique transport parameters are provided in the offer.

No group to any group:
 - In an offer, under all circumstances.
 - In an answer, never.

Any group to any other group:
 - In an offer, if the m-line was previously rejected.
 - In an answer, if the lines were offered as a bundle and there are
sufficient transport parameters on offer.

Is that the rules you would like to see?  I think that the last option
(splitting) is the only one that I haven't seen anyone else slavering
for.  The model permits it, but I'd rather prohibit features fix it up
later than start with something that ends up too permissive.

For example, it would be possible to split a bundle that had multiple
m-lines and only two sets of transport parameters like the following:

BUNDLE 1 2 3 4
mid:1  transport A
mid:2  transport A
mid:3  transport A
mid:4  transport B


Despite a (possible) preference from the offerer for bundling 1-3
together, 3 has been split off.

I'm sure that we can get the rules right, but I like avoiding these
sorts of little complications.