Re: API scope

On Sun, Feb 12, 2012 at 1:36 PM, Stefan Hakansson LK <
stefan.lk.hakansson@ericsson.com> 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?
>
> 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)


If we're just talking about createOffer/setLocalDesc (and not some
automatic exchange of the offer that occurs as a result, for the reasons
Harald mentions), I think this is an interesting idea. I thought of some
edge cases but I think they may be solvable.

- modification of the local session description: doable, as long as you
don't send an OFFER until you're ready, you can just call
setLocalDesc(OFFER) with your modified desc. Previous unanswered OFFERs are
simply discarded.
- adding multiple streams at once: similar problem as above, similar
solution - just perform 2/3 for each stream. (Other solution is to not
perform 2/3 until the next crank of the message pump, but that means you
can't send the offer right away.)
- callee behavior is different than caller behavior: we certainly don't
want the callee to automatically generate an OFFER, and we may not want the
callee to automatically ANSWER upon doing addStream (since that starts
media transmission), but I think we could apply the desc as a PRANSWER, e.g.

(separately) setRemoteDesc(OFFER)
1) addStream()
2) ld = createAnswer(remoteDesc(), null)
3) setLocalDesc(PRANSWER, ld)

with 2/3 being done automatically as in your example above.

>
>
>  and adding more API to make
>> something "simpler" doesn't seem like the right idea. Maybe someone else
>> has a better approach.
>>
>
>
>