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

[Adam Roach <[e-mail]>]

On 7/20/13 04:51, Christer Holmberg wrote:
> 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).

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 proposed mechanism is partial o/a. The requirement is important to 
certain key participants in the working group, so I would characterize 
having a mechanism to address it as essential.

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.

> *Q2a*: When sending a partial offer, the draft says that only the m= 
> line explicitly signaled is affected. Note, however, that you will 
> still signal information (e.g. the SDP version value, the group:BUNDLE 
> attribute etc) which affect the whole SDP, and if you have multiple 
> outstanding partial offers (for different m= lines) that can cause issues.
>
> *Q2b*: In addition, when using BUNDLE, modifying an m= line might 
> implicitly modify other m= lines, and there are rules (also indicated 
> in the draft) mandating identical SDP attribute values etc. So, if you 
> have multiple outstanding partial offers, you may end up with all kind 
> of different "BUNDLE collisions".
>
> *Q3*: If I send a partial offer, for a given m= line, can the answer 
> only contain that given m= line? What if the partial offer causes 
> other m= lines to be modified?
>

These three points are, as far as I can discern, the natural engineers' 
curiosity that leads us to want to start working on fleshing out a 
solution as soon as we understand its skeleton. I don't think it's time 
for that. I have answers for these questions, but I'm 100% certain that 
providing them would start a highly distracting, if interesting, 
conversation that would delay our nailing down the other aspects of the 
unified plan.

/a