Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handling - Glare

[Christer Holmberg <[e-mail]>]

Hi,

>> I do realize that the draft does not represent the complete glare solution. 
>
> Right, and I think it would be premature to dig into those details for their own sake at the moment.  So, before we go into a discussion of what I believe are minutiea, we 
> need to establish whether you're asking because it seems like an interesting problem to work on, or if you think that the approach has intractable flaws that would prevent 
> developing it to completion. (To be clear, even though it's not phrased as a question, I would expect you to indicate which of those is the case, Christer).

I have always thought that one of the downsides with SDP O/A is the fact that you always need to include the information for all streams when you send an Offer or Answer. Now, when you have 1 or 2 streams that is not a big issue. But, in the rtcweb context people have been talking about a much bigger number of streams, so it may become an issue.

So, I definitely think it seems like an interesting problem to work on.

I do think that there are issues with 'partial O/A'. But, as we both have said, this is not the moment to go into detailed discussions about the mechanism :)

> In the former case, I'd like to defer the discussion around what I believe are addressable open issues in the high-level sketch, and instead focus on 
> whether the overall "partial o/a" approach satisfies the needs of those parties for whom glare reduction is an important goal.
>
>> Q1: How essential part of the unified plan is having *A* working "partial o/a" solution? TECHNICALLY, the other parts of the unified plan do not depend 
>> on having a "partial o/a" solution, but I would like to know whether people (specially the draft authors) would be willing to move ahead with unified plan
>> even if we would not manage to specify a working "partial o/a" solution.
>
> Let's back up -- you're conflating mechanism with requirement here. The requirement is no glare in certain use cases (adding/removing streams).

The draft also talks about modifying streams (section 3.4.2). Are there specific modification use cases where no glare is important, or is it about being able to modify streams in general and avoid glare?

> The proposed mechanism is partial o/a.

Correct.

> The requirement is important to certain key participants in the working group, so I would characterize having a mechanism to address it as essential.

Ok.

> Keeping that in mind, "having a working 'partial o/a' solution," to re-use your phrasing, is utterly nonessential, since it is only one way to skin this cat. However, like
> I just said, having a working story for glare *is* essential. We've seen others (as I explained to my response to Paul, earlier), and may be able to come up with yet more.

So, moving ahead with unified plan basically means adopting the requirement to solve glare, but we may also look at other mechanisms?

Thanks for the clarification!

Regards,

Christer