Re: API scope

On 02/12/2012 07:36 PM, Stefan Hakansson LK wrote:
> On 02/10/2012 08:09 PM, Timothy B. Terriberry wrote:
>> Stefan Hakansson LK wrote:
>>> On 02/07/2012 12:20 AM, Timothy B. Terriberry wrote:
>>>> Similarly, it was argued at the F2F that ROAP was a subset of JSEP
>>>> (though if Cullen is right and switching codecs causes a period where
>>>> the receiver can't process what the sender is sending with JSEP, 
>>>> but not
>>>> with ROAP, I don't see how that can be true), but I think it would 
>>>> have
>>>> been hard to start with one and get to the other without working it 
>>>> out
>>>> first. Doing that may in fact be an interesting exercise (in terms of
>>>> getting more formalized semantics for things like 
>>>> setRemoteDescription()
>>>> before moving on to those that also require modifying the SDP 
>>>> passed to
>>>> setLocalDescription(), and separating out exactly what each one 
>>>> buys us
>>>> in terms of our use-cases).
>>>
>>> Tim, could you elaborate a bit more on your proposal? I think it sounds
>>> interesting, but want to understand more.
>>
>> I don't think I have a specific proposal, I meant it mostly as a
>> thought-experiment, along the lines of what Harald said: "[W]e should
>> make sure we don't add stuff in the first iteration that we aren't sure
>> we can live with as permanent features of the platform."
>>
>> As Jim Barnett has said elsewhere (echoing what I was trying to say in
>> the F2F), setLocalDescription() is currently way under-specified. In
>> addition to the list of things you can change in the SDP and the
>> validation that SDP must pass (which Jim pointed out), I'd add the
>> semantics of what happens when you pass it two different OFFERs in a row
>> (which, as I understand it, is where it departs from 3264 semantics). If
>> we can move forward without having to expose those things, with the
>> intention of adding them later, I think that gets us to a usable spec
>> faster.
>
> Agree fully.
>
>>
>> Unfortunately, the only way I've seen to do that is to add another API
>> call that combines createOffer() and setLocalDescription() (to ensure
>> the SDP is not modified between the two),
>
> I have come to a similar conclusion. In fact, I think the browser 
> should, when needed (as a result of add/removeStream, or even 
> add/removeTrack on a MS attached to the PeerConnection) do that 
> automatically. The reason being that every time that is done 
> (add/removeStream, or even add/removeTrack) some signaling to handle 
> this is needed - so the app would have to do
>
> 1. addStream (could be remove, or track addition/removal)
> 2. createOffer
> 3. setLocal
>
> why not have 2. and 3. happen automatically?
Because I don't think the browser knows what needs to happen.

For instance, if I am a passive participant in a conference who has an 
open MediaStream with an outgoing voice channel, and am then given the 
floor to give a presentation, I might need to do:

   1. AddStream(video, muted)
   2. AddStream(presentation)
   3. Change from low-bandwidth to high-bandwidth sound (by changing 
hints on my audio channel?)
   4. Check that my local conferencing enginge is willing to do what I 
wanted (createOffer, possibly setLocal)
   5. Check that my conferencing server is willing to do this (send 
offer, receive answer)
   4. Check microphone level and whether my hair looks good
   5. Hit the "OK, I have the floor" button

It's likely that 1-3 need to be done before any offer is sent. It's 
possible that there are offer/answer exchanges multiple places in this 
list - there might even be one when I hit "OK, I have the floor" - 
design here will depend strongly on whether this particular application 
thinks that offer/answer exchanges are done in milliseconds or minutes.

"Automatically" means (to me) "outside of JS control". I'm all in favour 
of having it be easy for the JS to do the right thing at the right time 
("stuff needs changing" callbacks). But I don't think we should link 
things together that often need to be kept separate.
>
> Then we also have to figure out a way that the application can modify 
> the local description. But perhaps the first step there is to 
> understand what you would want to change, what would be legal, and 
> then decide how (and if we want to move fast we could add that later).
>
> (speaking strictly as a contributor)
>
>> and adding more API to make
>> something "simpler" doesn't seem like the right idea. Maybe someone else
>> has a better approach.
>
>
>

Received on Monday, 13 February 2012 04:58:39 UTC