Re: API scope

On Fri, Feb 10, 2012 at 11:09 AM, Timothy B. Terriberry <
tterriberry@mozilla.com> 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.
>

To be fair, this is a general problem that affects any signaling API; we
haven't stipulated what can be changed in the remote SDP either, and the
app will always be able to touch that. In the end, we're going to have to
document this regardless.


> 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), and adding more API to make something
> "simpler" doesn't seem like the right idea. Maybe someone else has a better
> approach.
>
>
I'd be OK with not sending multiple unanswered OFFERs in a row for now if
it lets us move forward faster. I do think this particular case can be
handled simply though; if you send multiple OFFERs, you have to be ready to
receive media for any of them, which simply places constraints on what the
OFFERs can contain. Adding a source, for example, would not cause a
complication here, whereas changing recv codecs would.