Re: JSEP proposal

On Thu, Dec 22, 2011 at 5:11 AM, Cullen Jennings <fluffy@cisco.com> 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 http://tools.ietf.org/id/draft-cbran-rtcweb-media-00.txt and
> http://www.ietf.org/id/draft-ietf-rtcweb-security-01.txt
> >
> > 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.
IndexedDB: https://developer.mozilla.org/en/IndexedDB/IDBDatabaseException.

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?