Re: JSEP proposal

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? 

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.

Received on Thursday, 22 December 2011 10:12:05 UTC