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

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 27 May 2013 15:48 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 4EA1321F90FD for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 08:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdafept71zkX for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 08:47:56 -0700 (PDT)
Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 5009021F8F87 for <mmusic@ietf.org>; Mon, 27 May 2013 08:47:56 -0700 (PDT)
Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta07.westchester.pa.mail.comcast.net with comcast id h3hE1l0071ap0As573nvwX; Mon, 27 May 2013 15:47:55 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id h3nv1l00M3ZTu2S3i3nvb2; Mon, 27 May 2013 15:47:55 +0000
Message-ID: <51A3802A.1090203@alum.mit.edu>
Date: Mon, 27 May 2013 11:47:54 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
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 <martin.thomson@gmail.com>
References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <CAPvvaaJsPNk1DAJXYoc8aUgZ0ZayV_8q84W=Mm7vwuRRGuwC-g@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <CAOJ7v-398_MiXLWjexU0Z0xQju3A-zWuQFkWkJSLPA5UEGAu+g@mail.gmail.com> <CABkgnnXqBzteoxH2qWBw1Xn9PHt2r___UCsp1Eoq4o8_VWvBZg@mail.gmail.com> <CAOJ7v-2xXb=uz3jBAKSXhyJ2mU9BGvYHZ=dkeKcZTWov7udWKQ@mail.gmail.com> <519CCE58.3000807@alum.mit.edu> <CAMvTgcdPZfBTyzoBZGCdJiHX+TaL3_T8+MnxH8+6vQPFTD4ZOA@mail.gmail.com> <CAOJ7v-1tmfy4Fu05ChcpbZT=bO-zr05qtOh9Lnw5bprbUEnoDw@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB11350E214@xmb-aln-x02.cisco.com> <CABkgnnXgvEWtAs_yYu3ZZw0_TuFtgs_aOhpTrVaYZsfGd+hk+g@mail.gmail.com> <519E8CA6.1090009@alum.mit.edu> <CABkgnnUnB4GJxXQ=Yk6pOGhfX2iAc7wN=cowu1zAR=vbpC7p3A@mail.gmail.com>
In-Reply-To: <CABkgnnUnB4GJxXQ=Yk6pOGhfX2iAc7wN=cowu1zAR=vbpC7p3A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369669675; bh=4JMqZY7sx5HITz5jH5d1SckWIcM2Ec0c55g+lboOpRs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Y7alsuurUndAEeE/8IrDXDhs4OWTNZxg1GKjQaAkdfOrzKzPQ9rn2Xd4nkh6/NKFW MU4KxvbleiMxShWRk7bCne0BP9+h7/iRfACWwHNJCIJxQsLcqZnQDdRKkl1cp4w+77 CHAZlP0ezEGMfxfR8vB819JgzKHSJHuQDhyUnoUiBmbq39406AQTc8MXYR6GCqCF4H CwJDyn6YOFoyZe517gW6dZsTHp17eSA4MSl39jNMssUGXWVCqNetB1yDSNssnvBycD sArId2Vb2+CeskwdfQDOP7xz2mFROlEnm1IOvv0SgxKCYm3vlLhrRZMpXgFqDAh2zc RWqIWF/EljV1w==
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, Christer Holmberg <christer.holmberg@ericsson.com>, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 27 May 2013 15:48:02 -0000

On 5/23/13 8:14 PM, Martin Thomson wrote:
> On 23 May 2013 14:39, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>> I am pretty strongly opposed to restricting how one can recycle m-lines.
>> IMO this is a pretty basic and fundamental mechanism.
>
> What I'm suggesting would permit recycling(*).  However, if you are
> amending a session (as opposed to throwing it out entirely and
> starting over), then I would rather that you cannot (I suggest MUST
> NOT) change the BUNDLE affiliation of an m-line.

I disagree with this.

> This is - of course
> - only possible if you permit rejected m-lines to remain in a group.
>
> This really goes back to the whole BUNDLE negotiation model.  If a
> line is tentatively part of a BUNDLE group in the first exchange,
> confirmed in the second, do we permit splitting, reassignment, etc...
> in subsequent exchanges?

Yes, I think we do. IMO the following are some basic principles that 
ought to hold:

1) we can't allow an accepted m-line to be removed from a bundle while 
it shares an address/port with the bundle. We've settled that.

2) it should be possible to remove non-zero-port m-lines from a bundle 
offer, because the recipient needs to put them on separate addresses 
from the bundle.

3) There needs to be a way to handle the case where an answerer can't 
handle all the m-lines in a bundle offer as a single bundle, but could 
handle them as multiple bundles. I've proposed that this could be 
handled by refusing some of the m-lines in the bundle, and also removing 
them from the bundle. Then making a new offer that includes those 
m-lines in a new bundle. Removing the refused m-lines from the bundle 
could be handled at the time of rejection (the answer), or at the time 
of the new offer. I see no particular reason to prefer or legislate one 
way or the other.

4) In (3) I was thinking of a starting point where splitting occurred at 
the time of the initial offer for the bundle. The situation is a little 
different if the goal is to split an operational bundle, where the 
m-lines being split out already share an address/port with the bundle. 
(This is a less compelling case, but there are probably some reasons for 
it.) I see several approaches to this:

4a) new O/A that removes the m-lines from the old bundle and gives them 
unique address/ports. Later, another O/A that puts those m-lines into a 
new bundle.

4b) new O/A that rejects the m-lines and removes them from the old 
bundle. Later, another O/A that puts those m-lines into a new bundle.

4c) new O/A that rejects the m-lines, leaving them in the bundle. Later, 
another O/A that removes the rejected m-lines from the bundle. Later 
yet, another O/A that offers addresses for those m-lines and puts them 
into a new bundle.

4d) consolidate two steps in 4c: new O/A that rejects the m-lines, 
leaving them in the bundle. Later, another O/A that offers addresses for 
those m-lines and puts them into a new bundle.

4e) further consolidation: new O/A that removes previously active 
m-lines that had been previously bundled from their old bundle, gives 
them unique address/port values, and puts them into a new bundle.

There are basic primitives that show up above, that IMO ought to be ok:

A) reject an m-line (port zero) in an answer and remove from bundle.
    (This is basic behavior of 5888. Even if we relax it and allow
   rejected m-lines in groups we should still permit this.)

B) in a subsequent offer, reject (port zero) an m-line that was
    previously active and bundled, and remove it from the bundle.
    (This also seems to be basic behavior from 5888.)

C) in a subsequent offer, reject (port zero) an m-line that was
    previously active and bundled, but leave the m-line in the bundle.
    (Only if 5888 is extended to allow rejected m-lines in bundles.)

D) in a subsequent offer, remove a previously rejected m-line from a
    previously signaled bundle. (Only if 5888 is extended to allow
    rejected m-lines in bundles.)

E) in an answer, remove a zero port m-line in the offered bundle from
    the bundle in the answer.

F) in a subsequent offer, reuse an m-line that was rejected in the prior
    offer or answer, and was previously not in any bundle. Use this
    m-line for any purpose where a totally new m-line may be used.
    (This includes adding to an existing bundle, or proposing a new
    bundle.)

G) in a subsequent offer, reuse an m-line that was rejected in a prior
    offer or answer, and was previously in a bundle, as a new active
    m-line within the bundle. (According to the same rules as for
    adding an entirely new m-line to the bundle.)

H) Any change that can be done with two O/A exchanges using above
    rules, should be able to be done in one O/A exchange if the outcome
    of the first is deterministic. (Some examples:

    B = C+D

    Replace C+G with an offer that replaces a previously active m-line
    within a bundle with a proposal for a new m-line, also in the bundle,
    but otherwise entirely new.

    Replace an active m-line within a bundle with an unbundled m-line
    with a different address/port. (Skipping B.)

If we are going to revise 5888 so that we can keep rejected m-lines in 
bundle groups, then we must clearly define the distinction between a 
rejected m-line that is bundled from one that is not.

IMO the distinction is that an unbundled one has *no* significance other 
than as a placeholder required by the O/A requirement to preserve the 
ordering and numbering of m-lines. Including one in an offer means that 
this m-line is desired if and only if the bundle is accepted in the answer.

In that case, a rejected m-line in the bundle in an answer agrees that. 
Then a cleanup O/A will put the bundle port into that m-line, so that 
rejected m-lines would only be in bundles in a transient way.

	Thanks,
	Paul

> Or, do we permit the movement in and out of BUNGLE groups for any
> m-line?  If I want to migrate off one BUNDLE and to another, do I
> first reject the line and remove it from the BUNDLE group (exchange 1)
> and then re-animate it with a new BUNDLE group (exchange 2)?
>