Re: List of items noted during f2f

On 5 November 2012 11:31, Stefan Hakansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
>>> * Design signaling for _app_ rejecting to receive streams/tracks

Ahh, I got you.  Makes sense.

>>> * SDP offer validity lifetime: Decided to be “until stable state”
> My recollection was that Matthew towards the end of the discussion said
> something about that he was fine with "stable state" and that everyone
> seemed to agree (and I think that is what the scribe caught at 11:30 - 11:37
> in http://www.w3.org/2012/10/29-webrtc-irc).
>
> But we should discuss this some more on the list if this is not what others
> took away from that discussion.

My mistake, I only remembered half of that discussion arc.  We
concluded that if you needed to go to a server to "refine" SDP, then
the application would be required to call create{Offer,Answer} again
in order to guarantee that the SDP was valid and usable.

>>> * Candidate generation: Document pool model. Who?
>> ...default value of 0 that changes at setLocalDescription.  Implies
>> timing requirements.
> I don't follow. Could you elaborate (I'm sure you're right, I just want to
> understand your thinking)?

Sure, as I understand it, the decision was to add a new constraint for
the number of ICE candidate sets (or components) that are opened.
This constraint would default to zero such that no candidates would be
opened.  The default for the existing candidate set would remain at
"all", which would ensure that setting this new constraint (either at
construction or through updateIce or whenever) would trigger the
gathering of candidates up to this limit.  Setting a local description
would trigger the collection of any remaining candidates, or the
discarding of any excess candidates.

This is all contingent on getting trickle ICE done, of course.

Received on Monday, 5 November 2012 12:42:06 UTC