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.

There's a lot of complexity in that case.

In a situation where the offerer can predict what partitions might be
desired, you could use hierarchical bundling.  E.g., in the solution
proposed in
http://www.ietf.org/mail-archive/web/mmusic/current/msg10516.html, the
audio m= lines were put into one bundle and the video m= lines were
put into another bundle, and then the two bundles were put into one
large bundle.  That allows the answerer to use one transport
association for all media, or two transport associations (one for each
media type) so that they can have different QoS.

In CLUE situations, this might not work well, because the real
grouping is based on physical origin of the traffic, and one end can't
guess the physical configuration of the other end.

Another approach would be to have the grouping that marks the bundle
to be independent of which application-level flows are grouped with
which.  So one a=group:BUNDLE attribute just marks a bunch of m= lines
as being available for bundling, and each end provides the
address/ports for each m= line, which imply which m= lines are bundled
together.

That leads to the possibility that the bundling could be *different*
at each end of the connection.  E.g., at UA1, m= lines 1 and 2 could
use one port and m= lines 3 and 4 could use another port, while at
UA2, m= lines 1 and 3 use the same port and m= lines 2 and 4 use the
same port.  That isn't as insane as it sounds, if UA1 controls two
cameras at different addresses, each of which generates an audio and a
video stream, whereas UA2 controls an audio system (at one address)
and a video display (at another address).  The multiplexing and
demultiplexing works OK, but getting UA1 and UA2 to coordinate
everything is messy.

Thinking about these possibilities, it seems like Paul's proposal is
the simplest:

> Conceptually this isn't complex. But given the o/a rules in the grouping 
> framework I don't think it ca be achieved in the answer to the offer 
> that proposes a single bundle. It could be accomplished by:
> 
> - process the first answer in accord with (1) below - accepting the
>    m-lines that can go into one bundle, and rejecting (port=0) the
>    others.
> 
> - send a 2nd offer, with one bundle including the previously accepted
>    m-lines, and a separate bundle for the previously rejected m-lines.
>    Since mutual support of bundle is now presumed, this 2nd offer can
>    use a single addr/port, and a single set of ice candidates, for
>    all the m-lines in each bundle.

Of course, that does require that the bundling proposed in a later
offer doesn't have to closely match the bundling proposed in an
earlier offer in the O/A sequence.  That depends on the rules we write
regarding dependencies between successive offers/answers in an O/A
sequence, which we haven't written.  But at this point, I think that
those rules will be extremely loose, not because that's the
conceptually clean solution but because it would be difficult to write
strict rules that could be implemented reliably.

Dale