Subject: [MMUSIC] Feedback requested on requirements

From: [email-masked] (Dale R. Worley)
Date: Tue, 9 Apr 2013 11:39:45 -0400 (EDT)

DES F7  If an answerer that does understand the bundle mechanism
      processes an offer that contains a bundle, it must be able to (1)
      accept the bundle and selectively accept or reject each
      constituent RTP session within it, (2) reject the bundle as a
      whole, or (3) reject the bundling and selectively accept or reject
      each constituent RTP session as separate RTP sessions.

   Presumably answer (3) resembles that which would be produced by an
   answerer that does not understand the bundle mechanism.  It is a
   lower priority that the answerer can distinguish between accepting
   the bundle while rejecting all of its constituents, and rejecting the
   bundle as a whole.  But those two conditions differ conceptually
   regarding whether any "framing" actions of the bundle are performed.

Comments?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Apr 2013 03:06:45 +0800

I'd like to add to the cases that Dale lists below.

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.

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.

	Thanks,
	Paul

On 4/9/13 11:39 PM, Dale R. Worley wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 11 Apr 2013 19:07:46 -0400 (EDT)

> From: Paul Kyzivat <[email-masked]>
> 

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

>    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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 17 Apr 2013 10:01:02 +0200

>       each constituent RTP session as separate RTP sessions.

If you with "constituent RTP session within it" where it is a bundle
means the RTP media streams resulting from that particular SDP media
description (m= block) then I believe I agree with 1).

When it comes to 2) what makes this different from rejecting each m=
block within the bundle?

3) is required if legacy fallback at all going to be available.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 18 Apr 2013 16:48:20 -0400 (EDT)

> From: Magnus Westerlund <[email-masked]>
> 

Ah, yes, I meant "media description" instead of "RTP session".  I'll
fix that in the next version of the draft.

> When it comes to 2) what makes this different from rejecting each m=

If we allow bundles that contain zero media descriptions, then it is
conceptually possible that the bundle is accepted but all of the
constituent media descriptions are rejected, leaving the bundle
empty.  I do not see an immediate use for that, but in the long run,
it is desirable that the mechanism is able to express that.

Dale

---

From: Justin Uberti <[email-masked]>
Date: Fri, 19 Apr 2013 11:37:02 -0700

> it is desirable that the mechanism is able to express that.

The immediate use is to indicate that BUNDLE is supported by the endpoint,
even if the proposed BUNDLEd descriptions are rejected.

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 25 Apr 2013 15:34:30 -0400 (EDT)

> offered bundle into multiple bundles. You can view this as a variant of 

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

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 25 Apr 2013 15:34:56 -0400 (EDT)

> offered bundle into multiple bundles. You can view this as a variant of 

Some further thoughts on splitting an offered bundle:

One consideration is that when the answerer wants to split an offered
bundle, how does it do so in a way that takes into account what the
offerer wants?

For instance:

1. A offers a bundle 1,2,3,4.

2. B cannot bundle 3,4 with 1,2.

3. So B replies with bundle 1,2 and rejects 3,4 (or accepts them
unbundled).

4. Now B offers bundle 1,2 and bundle 3,4.

5. A can accept both bundles, so A accepts bundle 1,2 and bundle 3,4.

This is somewhat inefficient, since it takes two O/A cycles, but it's
simple, since A doesn't need to signal to B in some way what bundlings
it is willing to accept (e.g., with the hierarchial bundling concept
I've talked about).

Now suppose A wants to bundle 1,2,3,4 and 5,6,7,8, but B wants to
bundle 1,2,5,6 and 3,4,7,8.  The best bundling that can be achieved is
in four pairs, bundle 1,2, bundle 3,4, bundle 5,6, and bundle 7,8.
The best possible pattern for A and B to negotiate this would be
something like this:

1. A offers bundle 1,2,3,4 and bundle 5,6,7,8.

2. B accepts bundle 1,2 and bundle 5,6 and rejects 3, 4, 7, and 8.

3. B offers bundle 1,2, bundle 5,6, bundle 3,4, and bundle 7,8.
(Although it is willing to bundle 3,4 with 7,8, it remembers from A's
offer that it was unwilling to do so.  So B is limited to bundling the
four m= lines into two pairs.)

4. A accepts bundle 1,2, bundle 5,6, bundle 3,4, and bundle 7,8.

We have to make sure that A doesn't attempt to start a third cycle to
see if it can get 1,2 bundled with 3,4, etc.

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.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Apr 2013 11:13:21 -0400

Inline

> 5. A can accept both bundles, so A accepts bundle 1,2 and bundle 3,4.

Yeah, this is what I had in mind.

> The best possible pattern for A and B to negotiate this would be

This is "best" in terms of maximizing the possible bundle sizes while 
minimizing the number of O/A cycles.

> four m= lines into two pairs.)

This seems a reasonable strategy.

> see if it can get 1,2 bundled with 3,4, etc.

Another possibility would be for B offer bundles 1,2 and 5,6 because 
they already are in place, and 3,4,7,8 in hopes that it might be 
acceptable. Then A would refuse 7,8 and start another offer with 7,8 as 
a separate bundle. This is less efficient in this case, but makes fewer 
assumptions about the capabilities of A.

This seems like a bad choice. 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.)

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.

Having both as options makes things complicated. It could result in both 
sides waiting for the other to act. And having A make the second offer 
becomes a sort of "fetch a rock" exercise. 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."

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.

> offer should be the biggest bundling the offerer is willing to

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.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 29 Apr 2013 17:59:12 -0400 (EDT)

> I only bring it up because past experience 

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.

> *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 

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.

> 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.

> 5/6 ; 7,8 if B decides it wants to add another stream 9 it should offer 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Apr 2013 12:02:28 -0400

> other endpoint is not the endpoint you negotiated with previously.

Yep!

> reasons would offer all the bundling the endpoint is willing to

I think I agree with what you mean, but not with what I you wrote.
I think you mean:

"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 new offer should not disturb the bundles that
were accepted in the prior answer. New bundles may be offered including 
m-lines refused in the prior answer as well as new m-lines. New offers 
generated for other reasons would offer all the bundling the endpoint is 
willing to support."

This allows the 2nd O/A to introduce the remainder of the split bundle.

> send a number of probes to determine the answer.

For this to be practical we would have to come up with a way to signal 
the *reason* those m-lines were refused. Preconditions might be one way.

> supporting the stream at all.

This will probably be ok. But we need to recognize that it is a slight 
leap of faith.

> exactly two O/A cycles to determine the maximal bundling that both

It seems so.

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

In general I think we can assume that coincidences don't happen much. In 
particular, if conditions have changed at one endpoint such that it 
spontaneously needs to make a new offer that changes things from the 
current state, then it is exceedingly unlikely that the other endpoint 
will simultaneously have a change of state that it needs to introduce in 
the answer to that offer.

> produce an offer), then A might well have been replaced.

Yes, the offerless invite should be viewed as a solicitation for the 
full set of desires of the receiver.

> may be bundled in a way that B can't accept and may require B to

One thing to clarify in a case like this is how such an offer (adding a 
new m-line to an already active bundle) should be structured. I think, 
for practical reasons, it should have a single address/port for all of 
the m-lines that had previously been bundled. Not doing so will disturb 
the ongoing flows.

This *does* mean that it might get in trouble if the recipient turns out 
to be B' rather than B, and B' doesn't support bundle. Barring 
coincidences, this shouldn't happen with an unsolicited offer.

> require B to produce a second offer.

The offerless invite *might* be an indication that B has been replaced 
by B'. But there are also uses of offerless invites when that hasn't 
happened. And we can't screw things up in those cases.

If B has not been replaced, then I think it remains important that the 
existing bundles not be disturbed. So if that is a possibility, then A 
should send an offer that has the existing bundles as they are. If it 
turns out that B has been replaced by B', then that may be sub-optimal. 
And if B' doesn't support bundling, then it may not work at all.

It would be nice if we had a way, in the offerless invite, to send 
something so the receiver could discover if it was talking to the same 
party as before. AFAIK we don't have a way to do that.

> to receiving an offerless INVITE, it must offer the maximal bundling

As noted above, I don't think this works.

> were not bundled in the offer.)

Presumably in the 2nd offer, if a new bundle is proposed, then all the 
m-lines in that offer can share a single address/port, because support 
for bundling is already known.

	Thanks,
	Paul