Re: API scope

On 02/13/2012 06:57 AM, Justin Uberti wrote:
>
>
> On Sun, Feb 12, 2012 at 1:36 PM, Stefan Hakansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto: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.

Yes, I was thinking the same (and note that the app also controls when 
OFFERs are generated as nothing is done until a stable state is reached).

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

Or use stable-state to control.

> - 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)

I'm not sure I follow. The browser of the callee would have to generate 
an ANSWER to the OFFER, right? The caller's browser can not start 
streaming media until that ANSWER is received.

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

Received on Monday, 13 February 2012 08:18:47 UTC