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

[Paul Kyzivat <[e-mail]>]

On 5/23/13 8:14 PM, Martin Thomson wrote:
> On 23 May 2013 14:39, Paul Kyzivat <[e-mail]> 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)?
>