Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th)

[Paul Kyzivat <[e-mail]>]

(The quoting here is getting rather unmanageable.
I'm trimming, but maybe we need to start over fresh.)

On 6/14/13 4:45 PM, Christer Holmberg wrote:

>>>> Under what circumstances may the offerer presume to *know* whether the answerer supports BUNDLE?
>>>>
>>>> The minimal answer is that if an offer included a bundle group, and
>>>> the answer also contains a corresponding bundle group, then the answerer supported *that* bundle at the time of *that* answer, and continues to do so at least until there is another offer.
>>>
>>> Yes.
>>>
>>> I was actually thinking about removing the "until the Offerer knows" text, and simply generally say that the bundle address is negotiated by assigning a unique address to each "m=" line.
>>>
>>> But, as you want to be able to assign a bundle address to multiple "m=" lines before it has been negotiated, it would not work.
>>>
>>>> But we want to assume more - at least that if *a* bundle was
>>>> supported by both sides in one O/A exchange, then both sides can be
>>>> presumed to
>>>> *understand* bundle, including the use of the same address info for multiple m-lines in a bundle offer, in future offers within the same signaling session.
>>>
>>> I would rather say SDP session, to keep it independent from the signaling protocol. That is the same as for any other parameter you negotiate using SDP O/A - it's valid until re-negotiated.
>>
>> Sure, I think "SDP session" will work.
>>
>>>> Is, or should there be, a way to go back on that presumption - to
>>>> stop supporting bundle? I guess if an end wanted to stop supporting
>>>> bundle while a bundle was in effect it would need to send an offer that didn't include any bundles. But it might want to send such an offer just because it doesn't currently need a bundle though it still supports them.
>>>
>>> Sure, but if anyone then wants to start using BUNDLE again, it will send an Offer and suggest the usage.
>>
>> My point was that if support for bundle can be presumed, then it no longer is necessary to offer unique address info for each m-line when adding to bundles or proposing new bundles.
>
> Ok, I hear you. Yes, IF we allow that it is important that it is clear when one can assume that the Answerer supports BUNDLE.

In prior reply I sketched out my thoughts about what constitute 
reasonable evidence.

But IMO an offerer MAY presume support without any explicit evidence in 
the signaling if it wishes. This may be because it knows the relevant 
deployment environment guarantees it, or because it has some other 
signaling mechanism to learn it. Or it may simply want to play the odds.

I don't think we should forbid guessing. It is a judgement call, and in 
such a case the offerer must be prepared to cope with the consequences 
if the guess turns out to be wrong.

>> In particular, this becomes significant for the bundle splitting case:
>>
>> 1) X sends offer to Y proposing a bundle, uses unique address info
>> 2) Y sends answer to x accepting the bundle,
>>     but rejecting some of the m-lines in it
>> 3) X sends a BAS to Y to finalize the initial bundle.
>> 4) Y sends answer to X accepting the BAS
>> 5) Y sends offer to X keeping the existing bundle,
>>     and proposing a new bundle for the previously rejected
>>     m-lines. Because it knows X supports bundle, and it knows
>>     that X was willing to have the m-lines in question bundled,
>>     this offer is in the form of a BAS, with all the m-lines
>>     in the new bundle having common address info.
>> 6) X sends answer to Y, presumably accepting both bundles.
>>
>> In this case it is quite wasteful if Y has to provide separate address info for each of the m-lines in the new bundle, and then yet another BAS has to be exchanged to fix that up.
>>
>> Of course being able to presume support also is useful in cases where no bundle splitting is needed. E.g., Y was able to accept the initial bundle from X in full. Then later
>> it wanted to offer an additional separate bundle. And it could also cover the case where an initial O/A is done when no bundle is yet needed, but *support* for bundle is
>> negotiated. Then later, when a bundle is needed, it may be offered in BAS form, so only a single O/A is required.
>>
>> The above also points out another issue: (3) & (4) are quite a waste. It would be nice to be able to avoid them in this case. One way to achieve that would be to put the burden
>> on the answerer that accepts a bundle where the address info is not all the same to send the BAS. In this case that would mean that (5) would also serve as a substitute for (3), and
>> (6) would then substitute for (4).
>
> I understand what you're saying, and I'll dig more into it once I get -04 submitted :)

Sure!

> I have added it as an Open Issue in -04, though.

Thanks.

>> I'm still having trouble making sense of this. Let me break out some things to try and understand. (I'm trying to state what I think you mean, not as it ought to be written in a draft, just for maximal clarity.)
>>
>> It is the *answer* that selects the m-line that defines the bundle addresses for both offerer and answerer. Until then it isn't known.
>
> Correct.
>
>> Only after the bundle addresses are known may an offer be sent that has a common address for multiple m-lines in the bundle, and if so it must be the one that was previously defined as the bundle address.
>
> Correct.
>
>> As a consequence, on the initial offer that proposes a bundle, every m-line must have unique address info.
>
> Correct.
>
>> When sending an subsequent offer, after a bundle has previously been defined, (so the bundle addresses are known), multiple m-lines in that bundle *may* be offered with the same address info, but that address info must be the previously agreed bundle address.
>
> Correct.
>
>> As a consequence, to *change* a previously agreed bundle address, an offer must be sent where every m-line in the bundle has unique address info.
>
> Correct.
>
>> Does that accurately restate what you meant above?
>
> Yes.
>
>> (If so, you know that I don't agree - I find it much more prescriptive than it needs to be, with negative consequences. But lets be certain we agree what you are intending to say first.)
>
> It seems we have a common understanding of what is currently specified :)

Good. That is a start!

> And, even with your suggestion, the answerer would still select the bundle addresses for both the offerer and the answerer. But, there might of course
>   not be too many addresses to choose from in the offer (e.g. if each m- line in the offer has the suggested new bundle address).

Yes.

> Also, even with your suggestion I guess that at least the initial offer would need to have unique addresses for each m- line, as it is yet not known
>   whether BUNDLE is supported within that particular SDP session.

Not necessarily. I discussed this above.

>> ISTM that the problem is being driven by what is easy to describe, rather than what is useful to do, even though the actual implementation effort would probably be the same or even less difficult.
>>
>> While I do agree that clarity of explanation is important, that tells me we need to continue to work to find a clear way to express constraints without being over restrictive.
>>
>> I previously tried - offering a set of constraints on offers and answers that I thought covered the cases. I still think that could work.
>
> Ok, once I've submitted -04, I'll continue to work on text for that, while allowing people to review the rest of the procedures.

OK.

>>>> nit: I don't think this should say anything about the mid value that
>>>> was previously defined for the m-line. That implies that mid values must be preserved from one o/a to another. While they probably will in most cases I don't think that should be required.
>>>> If I want, I should be able to "relabel" the m-lines with new mid
>>>> values. This reduces the amount of state that is required to be preserved from one o/a to the next.
>>>>
>>>> The statement "remove an m-line from a bundle group" already implies
>>>> that the group does not contain a mid-value identifying that m-line
>>>> (in
>>>> *this* offer or answer).
>>>
>>> Maybe I could say that the mid value that was previously defined is no more valid, and must not be present in any Offer or Answer.
>>
>> The mid values from the previous o/a have *no* relevance to the new o/a.
>> It is *possible* (though not likely) that some of the same values may be used in the new offer to identify *different* m-lines. So saying that a value from a previous o/a must not be present is also not correct.
>>
>> I don't think you need to say anything about this. Possibly you could say that the bundle group identifies the m-lines that are to be in the bundle, and so must
>> not mention m-lines that are no longer in the bundle. But this is so obvious that stating it is likely to confuse people more than not stating it.
>
> The to-be-submitted text basically only says that the mid must no longer be used to associate the removed/rejected/disabled m- line with the BUNDLE group.

OK.

>>> As a side note, I intend to replace "unique address" and "bundle address" with "unique transport parameters" and "bundle transport parameters", as suggested by Martin.
>>>
>>> ...except in cases where the text actually talks about the IP address,
>>> that is :)
>>
>> WFM.
>
> It wasn't as easy to change as I first thought, so for now I keep "unique address" and "bundle address". But, I have added a definition, saying that it refers to the IP address and port.
>
> In a separate chapter I talk about ICE candidates, and other parameters, that have to be identical in bundled m- lines.

Sounds reasonable.

	Thanks,
	Paul