Re: [MMUSIC] "splitting" a bundle

[[e-mail] (Dale R. Worley)]

> From: Paul Kyzivat <[e-mail]>
> 
> I only bring it up because past experience 
> with O/A has shown that it is generally better for an offerer to say 
> what they want without making value judgements about the other party. It 
> becomes especially important if it turns out that the party you are 
> sending the offer to turns out to be different from the one you talked 
> to last. (That probably is nonsense here if these O/A cycles are 
> back-to-back.)

The difficulty in this case with always offering everything you want
is that the process never ends:  Each endpoint *wants* to bundle m=
lines that the other endpoint can't accept.

OTOH, you have to worry about the possiblity that at this moment, the
other endpoint is not the endpoint you negotiated with previously.

A solution is that if the endpoint is sending an offer to effect
bundling between m= lines that it disconnected from an *immediately*
preceding offer, the endpoint should offer no bundling that was not
proposed in the preceding offer.  New offers generated for other
reasons would offer all the bundling the endpoint is willing to
support.

> In all of the above, the behavior of B only makes sense if B feels it 
> *needs* all of these streams. Another possibility is that B simply 
> rejects the streams it can't accept when bundled as proposed, but 
> doesn't initiate another O/A cycle. Then if A feels those are important, 
> *it* can send another offer with them separately bundled.

The difficulty with that is that A doesn't know whether B rejected
them because it couldn't deal with the bundling or because B was
unable to utlize the m= line for some other reason.  A would have to
send a number of probes to determine the answer.

> But having B make the second 
> offer means it may need to take on faith "I don't know if these streams 
> are important, but my peer wanted them so I'll try to establish them."

B would only include the stream in a second offer if B would have
accepted the stream un-bundled, which means that B knows that A wants
the stream (whether or not A considers it "important") and that B can
support it, in which case we assume that the penalty for supporting
the stream without bundling is lower than the penalty for not
supporting the stream at all.

> These cases requiring multiple O/A cycles to get things arranged as 
> desired are starting to smell to me like the kinds of situations that 
> preconditions were designed for. Perhaps a new "bundle" precondition 
> would provide a way to sort out responsibilities and realize when to 
> keep trying and when to give up. But many consider preconditions too 
> heavy weight to use in practice. And they could prove difficult in JSEP.

It does resemble precondition situations.  But we can arrange for
exactly two O/A cycles to determine the maximal bundling that both
endpoints can support.

> > But if either side initiates a re-offer for some other reason, the new
> > offer should be the biggest bundling the offerer is willing to
> > support.
> 
> You mean, in the above case, after having agreed on bundles 1,2 ; 3/4 ; 
> 5/6 ; 7,8 if B decides it wants to add another stream 9 it should offer 
> 1,2,5,6 ; 3,4,7,8,9 ???
> 
> I *think* the new offer should include the new bundles in their current 
> operational form, with only one address/port per bundle. Doing otherwise 
> would disrupt the functioning of the current streams. Stream 9 could be 
> added to one of the existing bundles in the offer, but should have a 
> separate address/port.
> 
> That will probably break a scenario that is trying to do a 3pcc 
> transfer. I suspect that doing such a thing with bundled streams is 
> going to be *hard*, and will need to be considered separately.

The question is whether B thinks A might have been replaced by A'.

Now that you mention it, if B adds stream 9 (generating a new offer
for internal reasons), then it is very unlikely that A has been
replaced.  But if B receives an offerless INVITE (demanding that B
produce an offer), then A might well have been replaced.

If B receives an offer, there are three cases:

The offer may be from an A', in which case it's OK if B gives the best
response it can (according to the previous plan), and does a re-offer
if it needs to create new bundles to split an offered bundle.

The offer may be from A, generated for internal reasons, in which case
it looks very much like the previous SDP.  But, e.g., added m= lines
may be bundled in a way that B can't accept and may require B to
produce a second offer.

The offer may be from A, generated due to receiving an offerless
INVITE from an intermediate 3PCC controller, in which case (we assume)
it specifies the maximal bundling that A can support.  That may
require B to produce a second offer.

So it looks like we can soften the rules to:

If an endpoint makes an offer for what it sees as a new dialog, or due
to receiving an offerless INVITE, it must offer the maximal bundling
it supports.

If an endpoint receives an offer, it answers with the maximal bundling
that it supports that is a subset of the offered bundling.  (I say
"subset", as the answer necessarily has no more bundles than the
offer.)  The endpoing may then make a second offer that offers the
maximal bundling that it supports that is compatible with the received
offer.  ("Compatible" in the sense of bundling no two m= lines that
were not bundled in the offer.)

Dale