Re: JSEP proposal

On Thu, Dec 22, 2011 at 5:11 AM, Cullen Jennings <> wrote:

> On Dec 20, 2011, at 14:48 , Justin Uberti wrote:
> >
> >
> > If the JS calls createOffer(), then changes the offer a bit and then
> passes it to setLocalDescription, what things in the offer can JS change
> and what does it need to keep the same?
> >
> > I would think it could change anything other than the ICE information,
> provided that the new description is compatible with the requirements set
> out in and
> >
> > For example, it could rearrange or remove codecs, change payload type
> ids, etc. Given that the UA has to be able to handle arbitrary remote
> descriptions, handling modified local descriptions should not be hard.
> So if I had a mobile with a DSP that could do only one stream of HD video,
> would this resource get reserved on the createOffer or setLocal. I imaging
> that doing it in the setLocal makes more sense but that means we are going
> to frequently have cases where JS uses createOffer, gets and offer, changes
> nothing, then does setLocalSDP and the setLocalSDP call will fail. It's
> going to be very hard to describe what failed about the SDP. What sort of
> error did you imagine that setLocal and setRemote might return?

createOffer() is not intended to change state, it just generates an offer
from the inputs and current state; setLocalDescription is where this
reservation would occur.

I agree that setLocalDescription will fail in this case, but we should be
able to return an appropriate error via a specific PeerConnectionException
indicating a resource limit. Other HTML5 interfaces do this, e.g.

I've added a note to the open items section of the doc to figure out the
details of this exception.

> This issues of when to allocate and clean up resources needs to be worked
> through. For example, if an offer ends up offering two video codecs, it
> means both of theses need to be valid to receive RTP data. However if the
> far end sends a final answer, then we can free up the resources for any
> codec that was not negotiated, however other types of answers might mean we
> can not yet free up theses resources as someone still might send RTP using
> that codec. So just thinking out loud but we probably need a bit passed in
> when doing the setRemoteSDP that indicates information about deallocating
> resource. Specifically the example with the 180 and 200 probably need to
> have that bit set differently.

Good point, but wouldn't that affect the re-INVITE case as well? Or is the
180-then-200 scenario a true special case?

Also, how important is this deallocation? If the remote side says it
supports both codecs in its answer, won't you still need to keep both
codecs around?

Received on Tuesday, 3 January 2012 23:57:55 UTC