Re: API scope

On 02/13/2012 05:58 AM, Harald Alvestrand wrote:
> 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

This is great input, we've not been even close to this kind of detailed 
input on how use cases are solved. (And it is a good new use case as well).

>
> It's likely that 1-3 need to be done before any offer is sent.

I would just want to point out that also if the browser would 
automatically do the things I proposed (i.e. creatOffer, setLocal) 
earlier, the application is in full control. The browser won't do 
anything until it reaches a stable state.

So for this use case, I would do 1-3 between the same brackets, the 
browser would then do 4 (delivered to the app via a callback). The app 
can check the offer generated to see that it is happy, and if so do 5. I 
think the use can do "second 4" in parallel and then "second 5".


In addition, I think Adam's mail last week showed an idea where the 
offer created can be cancelled by calling "processSignalingMessage" with 
the generated offer (if I understand him correctly).
> 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.

Yes, I agree.

Thinking a bit more about this, having the mute state being changed 
through offer/answer can be a problem as it can take a while. (I think 
this has nothing to do with the API to allow JSEP, but is valid in any 
case.) Memory fades, but perhaps this was the reason while we originally 
had the text on that a muted Video track should play out as black. The 
receiving app can then easily detect this in a canvas element and 
locally do the processing wanted for a nice UI. This way things are much 
quicker (especially compared to a minutes long o/a :-) ).

>
> "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.

I agree fully. I want to help the process forward. If there are good 
reasons for separating addStream/createOffer/setLocal we should do it. 
My only objective is to make the simple case simple, not in any way to 
stop the advanced cases.

>>
>> 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 12:05:08 UTC