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

Paul Kyzivat <> Wed, 29 May 2013 14:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 010C021F9007 for <>; Wed, 29 May 2013 07:42:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2gYNI+P9ZRQG for <>; Wed, 29 May 2013 07:41:59 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:44:76:96:59:212]) by (Postfix) with ESMTP id C72FE21F8AD8 for <>; Wed, 29 May 2013 07:41:56 -0700 (PDT)
Received: from ([]) by with comcast id hoia1l0031ZXKqc5EqhwMM; Wed, 29 May 2013 14:41:56 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id hqhv1l01U3ZTu2S3hqhwoo; Wed, 29 May 2013 14:41:56 +0000
Message-ID: <>
Date: Wed, 29 May 2013 10:41:54 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Martin Thomson <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1369838516; bh=/Tp2eXqHKkG2nqsI/fqRfi/uIg9nLQENDVU5H8mA0IY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tjpXPj4s0h/zqknffVfQOtJoPW89vKuTQx4fepJLQOXDdnSh4rvkiO4+uQ7LslK37 99Wj6moStUjL8rdg0tXbEop33FaOcQJQgIeq7xn8mLessbEuuddp93HL2R56GKFpn0 Eh5NLpmF75KvE1jehfyhn//43zYSbcz/JB9TYMaQVVMOtjczw8fnqhs8psE6iIFM+0 JnMI5h1Ye2gx3UKrw7KMnD9fo6jTlY++ANpKCeMzFZMbdwS8aykyPUjA0D3OvILNMd lD+mDelwXu0qnocg8gvK+wYQByrUye9DQucPclKRIVo1XlJMc9K+40v26afgXy/ZSH JyQLd+5O1CloA==
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: Wed, 29 May 2013 14:42:05 -0000


On 5/28/13 12:34 PM, Martin Thomson wrote:
> 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
> properties:
>   - 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.

I don't understand what you mean here.
What are "sufficient transport parameters on offer"?
Do you mean when the addr/port in the offered m-line is unique?

I hadn't considered that case. I'm thinking its a bad idea to allow 
this, because it creates a bundling situation that the offerer hasn't 
consented to and has no way of refusing.

> Is that the rules you would like to see?

Yes, aside from my comment about the last one.
You describe it more clearly than I did.

> 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.

Without the last rule splitting is still possible, but it requires two 
O/A cycles. In the splitting case I have in mind, the initial offer puts 
a bunch of m-lines in one bundle. The answerer is decomposed so that it 
can't handle them all in one bundle. But perhaps it can handle them in 
two bundles. (The 2nd bundle has never been mentioned yet.)

So in its answer it refuses the m-lines that it wants in a separate 
bundle. Then it sends another offer, reviving the previously refused 
m-lines and putting them into a new bundle.

This can be accomplished with the rules you give above, dropping the 
last one. While it would be nice to accomplish this in a single O/A, I 
can see no way to accomplish that while giving both sides an opportunity 
to refuse what it can't do.


> 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:
> offer:
> BUNDLE 1 2 3 4
> mid:1  transport A
> mid:2  transport A
> mid:3  transport A
> mid:4  transport B
> answer:
> BUNDLE 1 2
> BUNDLE 4 3
> 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.