Re: [MMUSIC] "splitting" a bundle

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

> From: Paul Kyzivat <[e-mail]>
> 
> This has come up in CLUE, and pertains to cases where not all media 
> processing equipment is at the same address. In such cases bundling may 
> be supported, but more than one bundle may be required.
> 
> When this happens on the offering end the offerer can propose multiple 
> bundles from the beginning. But when it is the answerer that needs 
> things in separate bundles then it will need to "split" (partition) the 
> offered bundle into multiple bundles. You can view this as a variant of 
> (1)+(3) below.

I've given a little thought to the question of how a new offer may
amend the bundling situation created by the previous negotiation.  I
was considering the extremely general case when nested or hierarchial
bundling is allowed, but I think the conclusions are the same even
with one-level bundling:

1) It's natural to consider a rule "The new bundling must be
compatible with the old bundling", but it is extremely difficult to
come up with a definition of "compatible" that makes sense in all
cases, or even a definition that can be verified and enforced (unless
it is so strict as to be an impediment in practical situations).

2) There is little practical benefit to trying to align the new
bundling with the old bundling.

The reason for (2) is that after the offer/answer cycle, the endpoint
only needs to adjust its multiplexing/demultiplexing mechanism to
connect the correct application-level interfaces to the correct
transport endpoints.  That connection is actually fairly simple and
can be driven by a fairly small table that can be extracted directly
from the O/A SDP (even in complex cases such as hierarchial bundling
using an MMT-style syntax) -- there is no need to minimize the changes
from the previous bundling state to the new bundling state.

Dale